EP4143510A2 - Benutzerschnittstellen für personalisierte navigationsrouten - Google Patents

Benutzerschnittstellen für personalisierte navigationsrouten

Info

Publication number
EP4143510A2
EP4143510A2 EP21737905.6A EP21737905A EP4143510A2 EP 4143510 A2 EP4143510 A2 EP 4143510A2 EP 21737905 A EP21737905 A EP 21737905A EP 4143510 A2 EP4143510 A2 EP 4143510A2
Authority
EP
European Patent Office
Prior art keywords
vehicle
location
suggested
user interface
charge
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP21737905.6A
Other languages
English (en)
French (fr)
Inventor
Yunjae Kim
Brian James Andrich
Erik Gunnar Felix SODERVALL
Ting-yuan WU
Christopher Tremblay
Sean M. MEINERS
Brandon John VAN RYSWYK
Song Yang
Jinao ZHONG
Kun Chen
Moritz BAUM
Dennis Schieferdecker
Daniel Robert DELLING
Tobias ZUENDORF
Christian Joseph WEST
Michael Tobias WEGNER
Payas RAJAN
Eric D. SCHLAKMAN
Amanda Y. MIYAHIRA
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Apple Inc
Original Assignee
Apple Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/028,322 external-priority patent/US11846515B2/en
Application filed by Apple Inc filed Critical Apple Inc
Publication of EP4143510A2 publication Critical patent/EP4143510A2/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/36—Input/output arrangements for on-board computers
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/3407—Route searching; Route guidance specially adapted for specific applications
    • G01C21/3415—Dynamic re-routing, e.g. recalculating the route when the user deviates from calculated route or after detecting real-time traffic data or accidents
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/3453—Special cost functions, i.e. other than distance or default speed limit of road segments
    • G01C21/3461—Preferred or disfavoured areas, e.g. dangerous zones, toll or emission zones, intersections, manoeuvre types, segments such as motorways, toll roads, ferries
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/3453—Special cost functions, i.e. other than distance or default speed limit of road segments
    • G01C21/3469—Fuel consumption; Energy use; Emission aspects
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/36—Input/output arrangements for on-board computers
    • G01C21/3626—Details of the output of route guidance instructions
    • G01C21/3641—Personalized guidance, e.g. limited guidance on previously travelled routes
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/36—Input/output arrangements for on-board computers
    • G01C21/3664—Details of the user input interface, e.g. buttons, knobs or sliders, including those provided on a touch screen; remote controllers; input using gestures
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/36—Input/output arrangements for on-board computers
    • G01C21/3667—Display of a road map
    • G01C21/3676—Overview of the route on the road map
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/36—Input/output arrangements for on-board computers
    • G01C21/3679—Retrieval, searching and output of POI information, e.g. hotels, restaurants, shops, filling stations, parking facilities
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/36—Input/output arrangements for on-board computers
    • G01C21/3679—Retrieval, searching and output of POI information, e.g. hotels, restaurants, shops, filling stations, parking facilities
    • G01C21/3682—Retrieval, searching and output of POI information, e.g. hotels, restaurants, shops, filling stations, parking facilities output of POI information on a road map

Definitions

  • Field of the Disclosure relates generally to user interfaces that enable a user to view navigation routes that are customized for a respective vehicle.
  • Background of the Disclosure [0003] User interaction with electronic devices has increased significantly in recent years. These devices can be devices such as computers, tablet computers, televisions, multimedia devices, mobile devices, and the like.
  • an electronic device displays map user interfaces. In some circumstances, map user interfaces display suggested directions and routes.
  • Summary of the Disclosure [0005] Some embodiments described in this disclosure are directed to displaying suggested routes based on the characteristics of respective vehicles. Some embodiments described in this disclosure are directed to receiving data for respective vehicles from external sources. Some embodiments described in this disclosure are directed to anonymizing a vehicle identifier.
  • the embodiments described in this disclosure provide the user with the ability to view and select navigation routes that are customized for the user’s vehicles. This customization improves the user’s overall experience and interactions with the device. By customizing views and routes based on a user’s vehicle, embodiments also decrease user interaction time, which is particularly important where input devices are battery-operated.
  • personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users.
  • personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.
  • Fig.1A is a block diagram illustrating a portable multifunction device with a touch-sensitive display in accordance with some embodiments.
  • Fig.1B is a block diagram illustrating exemplary components for event handling in accordance with some embodiments.
  • Fig.2 illustrates a portable multifunction device having a touch screen in accordance with some embodiments.
  • Fig.3 is a block diagram of an exemplary multifunction device with a display and a touch-sensitive surface in accordance with some embodiments.
  • Fig.4A illustrates an exemplary user interface for a menu of applications on a portable multifunction device in accordance with some embodiments.
  • Fig.4B illustrates an exemplary user interface for a multifunction device with a touch-sensitive surface that is separate from the display in accordance with some embodiments.
  • Fig.5A illustrates a personal electronic device in accordance with some embodiments.
  • Fig.5B is a block diagram illustrating a personal electronic device in accordance with some embodiments.
  • Figs.5C-5D illustrate exemplary components of a personal electronic device having a touch-sensitive display and intensity sensors in accordance with some embodiments.
  • Figs.5E-5H illustrate exemplary components and user interfaces of a personal electronic device in accordance with some embodiments.
  • Figs.6A-6FF illustrate exemplary ways in which an electronic device displays customized navigation routes in accordance with some embodiments of the disclosure.
  • Fig.7 is a flow diagram illustrating a method of displaying customized navigation routes in accordance with some embodiments of the disclosure.
  • Figs.8A-8CC illustrate exemplary ways in which an electronic device receives information about characteristics of respective vehicles in accordance with some embodiments of the disclosure.
  • Fig.9 is a flow diagram illustrating a method of receiving information about characteristics of respective vehicles in accordance with some embodiments of the disclosure.
  • Figs.10A-10P illustrate exemplary ways in which a vehicle identifier is anonymized in accordance with some embodiments of the disclosure.
  • Fig.11 is a flow diagram illustrating a method of anonymizing a vehicle identifier in accordance with some embodiments of the disclosure.
  • Figs.12A-12G illustrate exemplary ways for efficiently identifying feasible routes for a vehicle based on different initial states of charge for the vehicle and/or based on the minimum desired buffer state of charge for the vehicle during the routes in accordance with some embodiments of the disclosure.
  • Fig.13 is a flow diagram illustrating a method of efficiently identifying feasible routes for a vehicle based on different initial states of charge for the vehicle and/or based on the minimum desired buffer state of charge for the vehicle during the routes in accordance with some embodiments of the disclosure.
  • Detailed Description [0028] The following description sets forth exemplary methods, parameters, and the like.
  • an electronic device displays customized navigation routes for a respective vehicle based on characteristics of the respective vehicle.
  • an electronic device receives the information on the characteristics of the respective vehicle from an external source (e.g., an application associated with the respective vehicle, a server, a website, etc.).
  • an electronic device anonymizes a user’s license plate (e.g., to be used in requesting customized routes from a navigation server).
  • resource-efficient methods for generating suggested routes are utilized. Such techniques can reduce the cognitive burden on a user who uses such devices and/or protect the privacy and/or security of sensitive incidents while providing navigation routes customized for the user’s vehicles. Further, such techniques can reduce processor and battery power otherwise wasted on redundant user inputs. [0030] Although the following description uses terms “first,” “second,” etc. to describe various elements, these elements should not be limited by the terms. These terms are only used to distinguish one element from another. For example, a first touch could be termed a second touch, and, similarly, a second touch could be termed a first touch, without departing from the scope of the various described embodiments. The first touch and the second touch are both touches, but they are not the same touch.
  • the phrase “if it is determined” or “if [a stated condition or event] is detected” is, optionally, construed to mean “upon determining” or “in response to determining” or “upon detecting [the stated condition or event]” or “in response to detecting [the stated condition or event],” depending on the context.
  • the device is a portable communications device, such as a mobile telephone, that also contains other functions, such as PDA and/or music player functions.
  • portable multifunction devices include, without limitation, the iPhone®, iPod Touch®, and iPad® devices from Apple Inc. of Cupertino, California.
  • device 100 is a portable computing system that is in communication (e.g., via wireless communication, via wired communication) with a display generation component.
  • the display generation component is configured to provide visual output, such as display via a CRT display, display via an LED display, or display via image projection.
  • the display generation component is integrated with the computer system (e.g., an integrated display, touch screen 112, etc.). In some embodiments, the display generation component is separate from the computer system (e.g., an external monitor, a projection system, etc.).
  • “displaying” content includes causing to display the content (e.g., video data rendered or decoded by display controller 156) by transmitting, via a wired or wireless connection, data (e.g., image data or video data) to an integrated or external display generation component to visually produce the content.
  • the electronic device optionally includes one or more other physical user-interface devices, such as a physical keyboard, a mouse, and/or a joystick.
  • the device typically supports a variety of applications, such as one or more of the following: a drawing application, a presentation application, a word processing application, a website creation application, a disk authoring application, a spreadsheet application, a gaming application, a telephone application, a video conferencing application, an e-mail application, an instant messaging application, a workout support application, a photo management application, a digital camera application, a digital video camera application, a web browsing application, a digital music player application, and/or a digital video player application.
  • applications such as one or more of the following: a drawing application, a presentation application, a word processing application, a website creation application, a disk authoring application, a spreadsheet application, a gaming application, a telephone application, a video conferencing application, an e-mail application, an instant messaging application, a workout support application, a photo management application
  • FIG.1A is a block diagram illustrating portable multifunction device 100 with touch-sensitive display system 112 in accordance with some embodiments.
  • Touch-sensitive display 112 is sometimes called a “touch screen” for convenience and is sometimes known as or called a “touch-sensitive display system.”
  • Device 100 includes memory 102 (which optionally includes one or more computer-readable storage mediums), memory controller 122, one or more processing units (CPUs) 120, peripherals interface 118, RF circuitry 108, audio circuitry 110, speaker 111, microphone 113, input/output (I/O) subsystem 106, other input control devices 116, and external port 124.
  • Device 100 optionally includes one or more optical sensors 164.
  • Device 100 optionally includes one or more contact intensity sensors 165 for detecting intensity of contacts on device 100 (e.g., a touch-sensitive surface such as touch-sensitive display system 112 of device 100).
  • Device 100 optionally includes one or more tactile output generators 167 for generating tactile outputs on device 100 (e.g., generating tactile outputs on a touch-sensitive surface such as touch-sensitive display system 112 of device 100 or touchpad 355 of device 300). These components optionally communicate over one or more communication buses or signal lines 103.
  • the term “intensity” of a contact on a touch-sensitive surface refers to the force or pressure (force per unit area) of a contact (e.g., a finger contact) on the touch-sensitive surface, or to a substitute (proxy) for the force or pressure of a contact on the touch-sensitive surface.
  • the intensity of a contact has a range of values that includes at least four distinct values and more typically includes hundreds of distinct values (e.g., at least 256).
  • Intensity of a contact is, optionally, determined (or measured) using various approaches and various sensors or combinations of sensors.
  • one or more force sensors underneath or adjacent to the touch-sensitive surface are, optionally, used to measure force at various points on the touch-sensitive surface.
  • force measurements from multiple force sensors are combined (e.g., a weighted average) to determine an estimated force of a contact.
  • a pressure-sensitive tip of a stylus is, optionally, used to determine a pressure of the stylus on the touch-sensitive surface.
  • the size of the contact area detected on the touch-sensitive surface and/or changes thereto, the capacitance of the touch-sensitive surface proximate to the contact and/or changes thereto, and/or the resistance of the touch-sensitive surface proximate to the contact and/or changes thereto are, optionally, used as a substitute for the force or pressure of the contact on the touch-sensitive surface.
  • the substitute measurements for contact force or pressure are used directly to determine whether an intensity threshold has been exceeded (e.g., the intensity threshold is described in units corresponding to the substitute measurements).
  • the substitute measurements for contact force or pressure are converted to an estimated force or pressure, and the estimated force or pressure is used to determine whether an intensity threshold has been exceeded (e.g., the intensity threshold is a pressure threshold measured in units of pressure).
  • the intensity threshold is a pressure threshold measured in units of pressure.
  • the term “tactile output” refers to physical displacement of a device relative to a previous position of the device, physical displacement of a component (e.g., a touch-sensitive surface) of a device relative to another component (e.g., housing) of the device, or displacement of the component relative to a center of mass of the device that will be detected by a user with the user’s sense of touch.
  • a component e.g., a touch-sensitive surface
  • another component e.g., housing
  • the tactile output generated by the physical displacement will be interpreted by the user as a tactile sensation corresponding to a perceived change in physical characteristics of the device or the component of the device.
  • a touch-sensitive surface e.g., a touch-sensitive display or trackpad
  • the user is, optionally, interpreted by the user as a “down click” or “up click” of a physical actuator button.
  • a user will feel a tactile sensation such as an “down click” or “up click” even when there is no movement of a physical actuator button associated with the touch-sensitive surface that is physically pressed (e.g., displaced) by the user’s movements.
  • movement of the touch-sensitive surface is, optionally, interpreted or sensed by the user as “roughness” of the touch-sensitive surface, even when there is no change in smoothness of the touch-sensitive surface. While such interpretations of touch by a user will be subject to the individualized sensory perceptions of the user, there are many sensory perceptions of touch that are common to a large majority of users.
  • a tactile output is described as corresponding to a particular sensory perception of a user (e.g., an “up click,” a “down click,” “roughness”)
  • the generated tactile output corresponds to physical displacement of the device or a component thereof that will generate the described sensory perception for a typical (or average) user.
  • device 100 is only one example of a portable multifunction device, and that device 100 optionally has more or fewer components than shown, optionally combines two or more components, or optionally has a different configuration or arrangement of the components.
  • the various components shown in FIG.1A are implemented in hardware, software, or a combination of both hardware and software, including one or more signal processing and/or application-specific integrated circuits.
  • Memory 102 optionally includes high-speed random access memory and optionally also includes non-volatile memory, such as one or more magnetic disk storage devices, flash memory devices, or other non-volatile solid-state memory devices.
  • Memory controller 122 optionally controls access to memory 102 by other components of device 100.
  • Peripherals interface 118 can be used to couple input and output peripherals of the device to CPU 120 and memory 102.
  • the one or more processors 120 run or execute various software programs and/or sets of instructions stored in memory 102 to perform various functions for device 100 and to process data.
  • peripherals interface 118, CPU 120, and memory controller 122 are, optionally, implemented on a single chip, such as chip 104.
  • RF (radio frequency) circuitry 108 receives and sends RF signals, also called electromagnetic signals.
  • RF circuitry 108 converts electrical signals to/from electromagnetic signals and communicates with communications networks and other communications devices via the electromagnetic signals.
  • RF circuitry 108 optionally includes well-known circuitry for performing these functions, including but not limited to an antenna system, an RF transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a CODEC chipset, a subscriber identity module (SIM) card, memory, and so forth.
  • SIM subscriber identity module
  • RF circuitry 108 optionally communicates with networks, such as the Internet, also referred to as the World Wide Web (WWW), an intranet and/or a wireless network, such as a cellular telephone network, a wireless local area network (LAN) and/or a metropolitan area network (MAN), and other devices by wireless communication.
  • the RF circuitry 108 optionally includes well-known circuitry for detecting near field communication (NFC) fields, such as by a short-range communication radio.
  • NFC near field communication
  • the wireless communication optionally uses any of a plurality of communications 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, Bluetooth Low Energy (BTLE), Wireless Fidelity (Wi-Fi) (e.g., IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, and/or IEEE 802.11ac), voice over Internet Protocol (VoIP), Wi-MAX, a protocol for e-mail (e.g., Internet message access protocol (IMAP) and/or post office protocol (POP)), instant messaging (e.
  • Audio circuitry 110, speaker 111, and microphone 113 provide an audio interface between a user and device 100.
  • Audio circuitry 110 receives audio data from peripherals interface 118, converts the audio data to an electrical signal, and transmits the electrical signal to speaker 111.
  • Speaker 111 converts the electrical signal to human-audible sound waves.
  • Audio circuitry 110 also receives electrical signals converted by microphone 113 from sound waves.
  • Audio circuitry 110 converts the electrical signal to audio data and transmits the audio data to peripherals interface 118 for processing. Audio data is, optionally, retrieved from and/or transmitted to memory 102 and/or RF circuitry 108 by peripherals interface 118.
  • audio circuitry 110 also includes a headset jack (e.g., 212, FIG.2).
  • the headset jack provides an interface between audio circuitry 110 and removable audio input/output peripherals, such as output-only headphones or a headset with both output (e.g., a headphone for one or both ears) and input (e.g., a microphone).
  • I/O subsystem 106 couples input/output peripherals on device 100, such as touch screen 112 and other input control devices 116, to peripherals interface 118.
  • I/O subsystem 106 optionally includes display controller 156, optical sensor controller 158, intensity sensor controller 159, haptic feedback controller 161, and one or more input controllers 160 for other input or control devices.
  • the one or more input controllers 160 receive/send electrical signals from/to other input control devices 116.
  • the other input control devices 116 optionally include physical buttons (e.g., push buttons, rocker buttons, etc.), dials, slider switches, joysticks, click wheels, and so forth.
  • input controller(s) 160 are, optionally, coupled to any (or none) of the following: a keyboard, an infrared port, a USB port, and a pointer device such as a mouse.
  • the one or more buttons e.g., 208, FIG.2
  • the one or more buttons optionally include a push button (e.g., 206, FIG.2).
  • the electronic device is a computer system that is in communication (e.g., via wireless communication, via wired communication) with one or more input devices.
  • the one or more input devices include a touch-sensitive surface (e.g., a trackpad, as part of a touch-sensitive display).
  • the one or more input devices include one or more camera sensors (e.g., one or more optical sensors 164 and/or one or more depth camera sensors 175), such as for tracking a user’s gestures (e.g., hand gestures) as input.
  • the one or more input devices are integrated with the computer system.
  • the one or more input devices are separate from the computer system.
  • a quick press of the push button optionally disengages a lock of touch screen 112 or optionally begins a process that uses gestures on the touch screen to unlock the device, as described in U.S. Patent Application 11/322,549, “Unlocking a Device by Performing Gestures on an Unlock Image,” filed December 23, 2005, U.S. Pat. No.7,657,849, which is hereby incorporated by reference in its entirety.
  • a longer press of the push button e.g., 206) optionally turns power to device 100 on or off.
  • the functionality of one or more of the buttons are, optionally, user-customizable.
  • Touch screen 112 is used to implement virtual or soft buttons and one or more soft keyboards.
  • Touch-sensitive display 112 provides an input interface and an output interface between the device and a user.
  • Display controller 156 receives and/or sends electrical signals from/to touch screen 112.
  • Touch screen 112 displays visual output to the user.
  • the visual output optionally includes graphics, text, icons, video, and any combination thereof (collectively termed “graphics”). In some embodiments, some or all of the visual output optionally corresponds to user-interface objects.
  • Touch screen 112 has a touch-sensitive surface, sensor, or set of sensors that accepts input from the user based on haptic and/or tactile contact.
  • Touch screen 112 and display controller 156 (along with any associated modules and/or sets of instructions in memory 102) detect contact (and any movement or breaking of the contact) on touch screen 112 and convert the detected contact into interaction with user-interface objects (e.g., one or more soft keys, icons, web pages, or images) that are displayed on touch screen 112.
  • user-interface objects e.g., one or more soft keys, icons, web pages, or images
  • a point of contact between touch screen 112 and the user corresponds to a finger of the user.
  • Touch screen 112 optionally uses LCD (liquid crystal display) technology, LPD (light emitting polymer display) technology, or LED (light emitting diode) technology, although other display technologies are used in other embodiments.
  • Touch screen 112 and display controller 156 optionally detect contact and any movement or breaking thereof using any of a plurality of touch sensing technologies now known or later developed, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with touch screen 112.
  • touch sensing technologies now known or later developed, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with touch screen 112.
  • projected mutual capacitance sensing technology is used, such as that found in the iPhone® and iPod Touch® from Apple Inc. of Cupertino, California.
  • a touch-sensitive display in some embodiments of touch screen 112 is, optionally, analogous to the multi-touch sensitive touchpads described in the following U.S.
  • touch screen 112 displays visual output from device 100, whereas touch-sensitive touchpads do not provide visual output.
  • a touch-sensitive display in some embodiments of touch screen 112 is described in the following applications: (1) U.S. Patent Application No.11/381,313, “Multipoint Touch Surface Controller,” filed May 2, 2006; (2) U.S. Patent Application No.10/840,862, “Multipoint Touchscreen,” filed May 6, 2004; (3) U.S.
  • Touch screen 112 optionally has a video resolution in excess of 100 dpi. In some embodiments, the touch screen has a video resolution of approximately 160 dpi.
  • the user optionally makes contact with touch screen 112 using any suitable object or appendage, such as a stylus, a finger, and so forth.
  • the user interface is designed to work primarily with finger-based contacts and gestures, which can be less precise than stylus-based input due to the larger area of contact of a finger on the touch screen.
  • the device translates the rough finger-based input into a precise pointer/cursor position or command for performing the actions desired by the user.
  • device 100 in addition to the touch screen, device 100 optionally includes a touchpad (not shown) for activating or deactivating particular functions.
  • the touchpad is a touch-sensitive area of the device that, unlike the touch screen, does not display visual output.
  • Device 100 also includes power system 162 for powering the various components.
  • Power system 162 optionally includes a power management system, one or more power sources (e.g., battery, alternating current (AC)), a recharging 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 in portable devices.
  • Power system 162 optionally also includes one or more optical sensors 164.
  • FIG.1A shows an optical sensor coupled to optical sensor controller 158 in I/O subsystem 106.
  • Optical sensor 164 optionally includes charge-coupled device (CCD) or complementary metal-oxide semiconductor (CMOS) phototransistors.
  • CCD charge-coupled device
  • CMOS complementary metal-oxide semiconductor
  • Optical sensor 164 receives light from the environment, projected through one or more lenses, and converts the light to data representing an image.
  • imaging module 143 also called a camera module
  • optical sensor 164 optionally captures still images or video.
  • an optical sensor is located on the back of device 100, opposite touch screen display 112 on the front of the device so that the touch screen display is enabled for use as a viewfinder for still and/or video image acquisition.
  • an optical sensor is located on the front of the device so that the user’s image is, optionally, obtained for video conferencing while the user views the other video conference participants on the touch screen display.
  • the position of optical sensor 164 can be changed by the user (e.g., by rotating the lens and the sensor in the device housing) so that a single optical sensor 164 is used along with the touch screen display for both video conferencing and still and/or video image acquisition.
  • Device 100 optionally also includes one or more contact intensity sensors 165.
  • FIG.1A shows a contact intensity sensor coupled to intensity sensor controller 159 in I/O subsystem 106.
  • Contact intensity sensor 165 optionally includes one or more piezoresistive strain gauges, capacitive force sensors, electric force sensors, piezoelectric force sensors, optical force sensors, capacitive touch-sensitive surfaces, or other intensity sensors (e.g., sensors used to measure the force (or pressure) of a contact on a touch-sensitive surface).
  • Contact intensity sensor 165 receives contact intensity information (e.g., pressure information or a proxy for pressure information) from the environment.
  • contact intensity information e.g., pressure information or a proxy for pressure information
  • at least one contact intensity sensor is collocated with, or proximate to, a touch-sensitive surface (e.g., touch- sensitive display system 112).
  • at least one contact intensity sensor is located on the back of device 100, opposite touch screen display 112, which is located on the front of device 100.
  • Device 100 optionally also includes one or more proximity sensors 166.
  • FIG.1A shows proximity sensor 166 coupled to peripherals interface 118.
  • proximity sensor 166 is, optionally, coupled to input controller 160 in I/O subsystem 106.
  • Proximity sensor 166 optionally performs as described in U.S.
  • the proximity sensor turns off and disables touch screen 112 when the multifunction device is placed near the user’s ear (e.g., when the user is making a phone call).
  • Device 100 optionally also includes one or more tactile output generators 167.
  • FIG.1A shows a tactile output generator coupled to haptic feedback controller 161 in I/O subsystem 106.
  • Tactile output generator 167 optionally includes one or more electroacoustic devices such as speakers or other audio components and/or electromechanical devices that convert energy into linear motion such as a motor, solenoid, electroactive polymer, piezoelectric actuator, electrostatic actuator, or other tactile output generating component (e.g., a component that converts electrical signals into tactile outputs on the device).
  • Contact intensity sensor 165 receives tactile feedback generation instructions from haptic feedback module 133 and generates tactile outputs on device 100 that are capable of being sensed by a user of device 100.
  • At least one tactile output generator is collocated with, or proximate to, a touch-sensitive surface (e.g., touch-sensitive display system 112) and, optionally, generates a tactile output by moving the touch-sensitive surface vertically (e.g., in/out of a surface of device 100) or laterally (e.g., back and forth in the same plane as a surface of device 100).
  • at least one tactile output generator sensor is located on the back of device 100, opposite touch screen display 112, which is located on the front of device 100.
  • Device 100 optionally also includes one or more accelerometers 168.
  • FIG.1A shows accelerometer 168 coupled to peripherals interface 118.
  • accelerometer 168 is, optionally, coupled to an input controller 160 in I/O subsystem 106.
  • Accelerometer 168 optionally performs as described in U.S. Patent Publication No.20050190059, “Acceleration- based Theft Detection System for Portable Electronic Devices,” and U.S. Patent Publication No. 20060017692, “Methods And Apparatuses For Operating A Portable Device Based On An Accelerometer,” both of which are incorporated by reference herein in their entirety.
  • information is displayed on the touch screen display in a portrait view or a landscape view based on an analysis of data received from the one or more accelerometers.
  • Device 100 optionally includes, in addition to accelerometer(s) 168, a magnetometer (not shown) and a GPS (or GLONASS or other global navigation system) receiver (not shown) for obtaining information concerning the location and orientation (e.g., portrait or landscape) of device 100.
  • the software components stored in memory 102 include operating system 126, communication module (or set of instructions) 128, contact/motion module (or set of instructions) 130, graphics module (or set of instructions) 132, text input module (or set of instructions) 134, Global Positioning System (GPS) module (or set of instructions) 135, and applications (or sets of instructions) 136.
  • GPS Global Positioning System
  • memory 102 (FIG.1A) or 370 (FIG.3) stores device/global internal state 157, as shown in FIGS.1A and 3.
  • Device/global internal state 157 includes one or more of: active application state, indicating which applications, if any, are currently active; display state, indicating what applications, views or other information occupy various regions of touch screen display 112; sensor state, including information obtained from the device’s various sensors and input control devices 116; and location information concerning the device’s location and/or attitude.
  • Operating system 126 e.g., Darwin, RTXC, LINUX, UNIX, OS X, iOS, WINDOWS, or an embedded operating system such as VxWorks
  • Operating system 126 includes various software components and/or drivers for controlling and managing general system tasks (e.g., memory management, storage device control, power management, etc.) and facilitates communication between various hardware and software components.
  • Communication module 128 facilitates communication with other devices over one or more external ports 124 and also includes various software components for handling data received by RF circuitry 108 and/or external port 124.
  • External port 124 e.g., Universal Serial Bus (USB), FIREWIRE, etc.
  • USB Universal Serial Bus
  • FIREWIRE FireWire
  • the external port is a multi-pin (e.g., 30-pin) connector that is the same as, or similar to and/or compatible with, the 30-pin connector used on iPod® (trademark of Apple Inc.) devices.
  • Contact/motion module 130 optionally detects contact with touch screen 112 (in conjunction with display controller 156) and other touch-sensitive devices (e.g., a touchpad or physical click wheel).
  • Contact/motion module 130 includes various software components for performing various operations related to detection of contact, such as determining if contact has occurred (e.g., detecting a finger-down event), determining an intensity of the contact (e.g., the force or pressure of the contact or a substitute for the force or pressure of the contact), determining if there is movement of the contact and tracking the movement across the touch- sensitive surface (e.g., detecting one or more finger-dragging events), and determining if the contact has ceased (e.g., detecting a finger-up event or a break in contact).
  • Contact/motion module 130 receives contact data from the touch-sensitive surface.
  • Determining movement of the point of contact optionally includes determining speed (magnitude), velocity (magnitude and direction), and/or an acceleration (a change in magnitude and/or direction) of the point of contact. These operations are, optionally, applied to single contacts (e.g., one finger contacts) or to multiple simultaneous contacts (e.g., “multitouch”/multiple finger contacts).
  • contact/motion module 130 and display controller 156 detect contact on a touchpad.
  • contact/motion module 130 uses a set of one or more intensity thresholds to determine whether an operation has been performed by a user (e.g., to determine whether a user has “clicked” on an icon).
  • At least a subset of the intensity thresholds are determined in accordance with software parameters (e.g., the intensity thresholds are not determined by the activation thresholds of particular physical actuators and can be adjusted without changing the physical hardware of device 100).
  • a mouse “click” threshold of a trackpad or touch screen display can be set to any of a large range of predefined threshold values without changing the trackpad or touch screen display hardware.
  • a user of the device is provided with software settings for adjusting one or more of the set of intensity thresholds (e.g., by adjusting individual intensity thresholds and/or by adjusting a plurality of intensity thresholds at once with a system- level click “intensity” parameter).
  • Contact/motion module 130 optionally detects a gesture input by a user. Different gestures on the touch-sensitive surface have different contact patterns (e.g., different motions, timings, and/or intensities of detected contacts). Thus, a gesture is, optionally, detected by detecting a particular contact pattern. For example, detecting a finger tap gesture includes detecting a finger-down event followed by detecting a finger-up (liftoff) event at the same position (or substantially the same position) as the finger-down event (e.g., at the position of an icon).
  • detecting a finger tap gesture includes detecting a finger-down event followed by detecting a finger-up (liftoff) event at the same position (or substantially the same position) as the finger-down event (e.g., at the position of an icon).
  • detecting a finger swipe gesture on the touch-sensitive surface includes detecting a finger-down event followed by detecting one or more finger-dragging events, and subsequently followed by detecting a finger-up (liftoff) event.
  • Graphics module 132 includes various known software components for rendering and displaying graphics on touch screen 112 or other display, including components for changing the visual impact (e.g., brightness, transparency, saturation, contrast, or other visual property) of graphics that are displayed.
  • the term “graphics” includes any object that can be displayed to a user, including, without limitation, text, web pages, icons (such as user-interface objects including soft keys), digital images, videos, animations, and the like.
  • graphics module 132 stores data representing graphics to be used. Each graphic is, optionally, assigned a corresponding code. Graphics module 132 receives, from applications etc., one or more codes specifying graphics to be displayed along with, if necessary, coordinate data and other graphic property data, and then generates screen image data to output to display controller 156. [0069] Haptic feedback module 133 includes various software components for generating instructions used by tactile output generator(s) 167 to produce tactile outputs at one or more locations on device 100 in response to user interactions with device 100.
  • Text input module 134 which is, optionally, a component of graphics module 132, provides soft keyboards for entering text in various applications (e.g., contacts 137, e-mail 140, IM 141, browser 147, and any other application that needs text input).
  • GPS module 135 determines the location of the device and provides this information for use in various applications (e.g., to telephone 138 for use in location-based dialing; to camera 143 as picture/video metadata; and to applications that provide location-based services such as weather widgets, local yellow page widgets, and map/navigation widgets).
  • Applications 136 optionally include the following modules (or sets of instructions), or a subset or superset thereof: ⁇ Contacts module 137 (sometimes called an address book or contact list); ⁇ Telephone module 138; ⁇ Video conference module 139; ⁇ E-mail client module 140; ⁇ Instant messaging (IM) module 141; ⁇ Workout support module 142; ⁇ Camera module 143 for still and/or video images; ⁇ Image management module 144; ⁇ Video player module; ⁇ Music player module; ⁇ Browser module 147; ⁇ Calendar module 148; ⁇ Widget modules 149, which optionally include one or more of: weather widget 149-1, stocks widget 149-2, calculator widget 149-3, alarm clock widget 149-4, dictionary widget 149-5, and other widgets obtained by the user, as well as user-created widgets 149-6; ⁇ Widget creator module 150 for making user-created widgets 149-6; ⁇ Search module 151; ⁇ Video and music player module 152, which merges video player module and music player
  • Examples of other applications 136 that are, optionally, stored in memory 102 include other word processing applications, other image editing applications, drawing applications, presentation applications, JAVA-enabled applications, encryption, digital rights management, voice recognition, and voice replication
  • contacts module 137 are, optionally, used to manage an address book or contact list (e.g., stored in application internal state 192 of contacts module 137 in memory 102 or memory 370), including: adding name(s) to the address book; deleting name(s) from the address book; associating telephone number(s), e- mail address(es), physical address(es) or other information with a name; associating an image with a name; categorizing and sorting names; providing telephone numbers or e-mail addresses to initiate and/or facilitate communications by telephone 138, video conference module 139, e- mail 140, or IM 141; and so forth.
  • telephone module 138 are optionally, used to enter a sequence of characters corresponding to a telephone number, access one or more telephone numbers in contacts module 137, modify a telephone number that has been entered, dial a respective telephone number, conduct a conversation, and disconnect or hang up when the conversation is completed.
  • the wireless communication optionally uses any of a plurality of communications standards, protocols, and technologies.
  • video conference module 139 includes executable instructions to initiate, conduct, and terminate a video conference between a user and one or more other participants in accordance with user instructions.
  • e-mail client module 140 includes executable instructions to create, send, receive, and manage e-mail in response to user instructions.
  • the instant messaging module 141 includes executable instructions to enter a sequence of characters corresponding to an instant message, to modify previously entered characters, to transmit a respective instant message (for example, using a Short Message Service (SMS) or Multimedia Message Service (MMS) protocol for telephony-based instant messages or using XMPP, SIMPLE, or IMPS for Internet-based instant messages), to receive instant messages, and to view received instant messages.
  • SMS Short Message Service
  • MMS Multimedia Message Service
  • XMPP extensible Markup Language
  • SIMPLE Session Initiation Protocol
  • IMPS Internet Messaging Protocol
  • transmitted and/or received instant messages optionally include graphics, photos, audio files, video files and/or other attachments as are supported in an MMS and/or an Enhanced Messaging Service (EMS).
  • EMS Enhanced Messaging Service
  • instant messaging refers to both telephony-based messages (e.g., messages sent using SMS or MMS) and Internet-based messages (e.g., messages sent using XMPP, SIMPLE, or IMPS).
  • workout support module 142 includes executable instructions to create workouts (e.g., with time, distance, and/or calorie burning goals); communicate with workout sensors (sports devices); receive workout sensor data; calibrate sensors used to monitor a workout; select and play music for a workout; and display, store, and transmit workout data.
  • create workouts e.g., with time, distance, and/or calorie burning goals
  • communicate with workout sensors sports devices
  • receive workout sensor data calibrate sensors used to monitor a workout
  • select and play music for a workout and display, store, and transmit workout data.
  • camera module 143 includes executable instructions to capture still images or video (including a video stream) and store them into memory 102, modify characteristics of a still image or video, or delete a still image or video from memory 102.
  • image management module 144 includes executable instructions to arrange, modify (e.g., edit), or otherwise manipulate, label, delete, present (e.g., in a digital slide show or album), and store still and/or video images.
  • browser module 147 includes executable instructions to browse the Internet in accordance with user instructions, including searching, linking to, receiving, and displaying web pages or portions thereof, as well as attachments and other files linked to web pages.
  • calendar module 148 includes executable instructions to create, display, modify, and store calendars and data associated with calendars (e.g., calendar entries, to- do lists, etc.) in accordance with user instructions.
  • widget modules 149 are mini-applications that are, optionally, downloaded and used by a user (e.g., weather widget 149-1, stocks widget 149-2, calculator widget 149-3, alarm clock widget 149-4, and dictionary widget 149-5) or created by the user (e.g., user-created widget 149- 6).
  • a widget includes an HTML (Hypertext Markup Language) file, a CSS (Cascading Style Sheets) file, and a JavaScript file.
  • a widget includes an XML (Extensible Markup Language) file and a JavaScript file (e.g., Yahoo! Widgets).
  • XML Extensible Markup Language
  • JavaScript JavaScript
  • the widget creator module 150 are, optionally, used by a user to create widgets (e.g., turning a user-specified portion of a web page into a widget).
  • search module 151 includes executable instructions to search for text, music, sound, image, video, and/or other files in memory 102 that match one or more search criteria (e.g., one or more user-specified search terms) in accordance with user instructions.
  • search criteria e.g., one or more user-specified search terms
  • video and music player module 152 includes executable instructions that allow the user to download and play back recorded music and other sound files stored in one or more file formats, such as MP3 or AAC files, and executable instructions to display, present, or otherwise play back videos (e.g., on touch screen 112 or on an external, connected display via external port 124).
  • device 100 optionally includes the functionality of an MP3 player, such as an iPod (trademark of Apple Inc.).
  • notes module 153 includes executable instructions to create and manage notes, to-do lists, and the like in accordance with user instructions.
  • map module 154 are, optionally, used to receive, display, modify, and store maps and data associated with maps (e.g., driving directions, data on stores and other points of interest at or near a particular location, and other location-based data) in accordance with user instructions.
  • online video module 155 includes instructions that allow the user to access, browse, receive (e.g., by streaming and/or download), play back (e.g., on the touch screen or on an external, connected display via external port 124), send an e-mail with a link to a particular online video, and otherwise manage online videos in one or more file formats, such as H.264.
  • instant messaging module 141 rather than e-mail client module 140, is used to send a link to a particular online video.
  • modules e.g., sets of instructions
  • video player module is, optionally, combined with music player module into a single module (e.g., video and music player module 152, FIG.1A).
  • memory 102 optionally stores a subset of the modules and data structures identified above.
  • memory 102 optionally stores additional modules and data structures not described above.
  • device 100 is a device where operation of a predefined set of functions on the device is performed exclusively through a touch screen and/or a touchpad.
  • the number of physical input control devices (such as push buttons, dials, and the like) on device 100 is, optionally, reduced.
  • the predefined set of functions that are performed exclusively through a touch screen and/or a touchpad optionally include navigation between user interfaces.
  • the touchpad when touched by the user, navigates device 100 to a main, home, or root menu from any user interface that is displayed on device 100.
  • a “menu button” is implemented using a touchpad.
  • the menu button is a physical push button or other physical input control device instead of a touchpad.
  • FIG.1B is a block diagram illustrating exemplary components for event handling in accordance with some embodiments.
  • memory 102 (FIG.1A) or 370 (FIG.3) includes event sorter 170 (e.g., in operating system 126) and a respective application 136-1 (e.g., any of the aforementioned applications 137-151, 155, 380-390).
  • Event sorter 170 receives event information and determines the application 136-1 and application view 191 of application 136-1 to which to deliver the event information.
  • Event sorter 170 includes event monitor 171 and event dispatcher module 174.
  • application 136-1 includes application internal state 192, which indicates the current application view(s) displayed on touch-sensitive display 112 when the application is active or executing.
  • device/global internal state 157 is used by event sorter 170 to determine which application(s) is (are) currently active, and application internal state 192 is used by event sorter 170 to determine application views 191 to which to deliver event information.
  • application internal state 192 includes additional information, such as one or more of: resume information to be used when application 136-1 resumes execution, user interface state information that indicates information being displayed or that is ready for display by application 136-1, a state queue for enabling the user to go back to a prior state or view of application 136-1, and a redo/undo queue of previous actions taken by the user.
  • Event monitor 171 receives event information from peripherals interface 118. Event information includes information about a sub-event (e.g., a user touch on touch-sensitive display 112, as part of a multi-touch gesture).
  • Peripherals interface 118 transmits information it receives from I/O subsystem 106 or a sensor, such as proximity sensor 166, accelerometer(s) 168, and/or microphone 113 (through audio circuitry 110). Information that peripherals interface 118 receives from I/O subsystem 106 includes information from touch-sensitive display 112 or a touch-sensitive surface. [0098] In some embodiments, event monitor 171 sends requests to the peripherals interface 118 at predetermined intervals. In response, peripherals interface 118 transmits event information. In other embodiments, peripherals interface 118 transmits event information only when there is a significant event (e.g., receiving an input above a predetermined noise threshold and/or for more than a predetermined duration).
  • a significant event e.g., receiving an input above a predetermined noise threshold and/or for more than a predetermined duration.
  • event sorter 170 also includes a hit view determination module 172 and/or an active event recognizer determination module 173.
  • Hit view determination module 172 provides software procedures for determining where a sub-event has taken place within one or more views when touch-sensitive display 112 displays more than one view. Views are made up of controls and other elements that a user can see on the display.
  • Another aspect of the user interface associated with an application is a set of views, sometimes herein called application views or user interface windows, in which information is displayed and touch-based gestures occur.
  • the application views (of a respective application) in which a touch is detected optionally correspond to programmatic levels within a programmatic or view hierarchy of the application.
  • Hit view determination module 172 receives information related to sub-events of a touch-based gesture. When an application has multiple views organized in a hierarchy, hit view determination module 172 identifies a hit view as the lowest view in the hierarchy which should handle the sub-event. In most circumstances, the hit view is the lowest level view in which an initiating sub-event occurs (e.g., the first sub-event in the sequence of sub-events that form an event or potential event).
  • the hit view typically receives all sub-events related to the same touch or input source for which it was identified as the hit view.
  • Active event recognizer determination module 173 determines which view or views within a view hierarchy should receive a particular sequence of sub-events. In some embodiments, active event recognizer determination module 173 determines that only the hit view should receive a particular sequence of sub-events. In other embodiments, active event recognizer determination module 173 determines that all views that include the physical location of a sub-event are actively involved views, and therefore determines that all actively involved views should receive a particular sequence of sub-events.
  • Event dispatcher module 174 dispatches the event information to an event recognizer (e.g., event recognizer 180). In embodiments including active event recognizer determination module 173, event dispatcher module 174 delivers the event information to an event recognizer determined by active event recognizer determination module 173. In some embodiments, event dispatcher module 174 stores in an event queue the event information, which is retrieved by a respective event receiver 182.
  • operating system 126 includes event sorter 170.
  • application 136-1 includes event sorter 170.
  • event sorter 170 is a stand-alone module, or a part of another module stored in memory 102, such as contact/motion module 130.
  • application 136-1 includes a plurality of event handlers 190 and one or more application views 191, each of which includes instructions for handling touch events that occur within a respective view of the application’s user interface.
  • Each application view 191 of the application 136-1 includes one or more event recognizers 180.
  • a respective application view 191 includes a plurality of event recognizers 180.
  • one or more of event recognizers 180 are part of a separate module, such as a user interface kit (not shown) or a higher level object from which application 136-1 inherits methods and other properties.
  • a respective event handler 190 includes one or more of: data updater 176, object updater 177, GUI updater 178, and/or event data 179 received from event sorter 170.
  • Event handler 190 optionally utilizes or calls data updater 176, object updater 177, or GUI updater 178 to update the application internal state 192.
  • one or more of the application views 191 include one or more respective event handlers 190.
  • a respective event recognizer 180 receives event information (e.g., event data 179) from event sorter 170 and identifies an event from the event information.
  • Event recognizer 180 includes event receiver 182 and event comparator 184.
  • event recognizer 180 also includes at least a subset of: metadata 183, and event delivery instructions 188 (which optionally include sub-event delivery instructions).
  • Event receiver 182 receives event information from event sorter 170.
  • the event information includes information about a sub-event, for example, a touch or a touch movement.
  • the event information also includes additional information, such as location of the sub-event.
  • the event information optionally also includes speed and direction of the sub-event.
  • events include rotation of the device from one orientation to another (e.g., from a portrait orientation to a landscape orientation, or vice versa), and the event information includes corresponding information about the current orientation (also called device attitude) of the device.
  • Event comparator 184 compares the event information to predefined event or sub- event definitions and, based on the comparison, determines an event or sub-event, or determines or updates the state of an event or sub-event.
  • event comparator 184 includes event definitions 186.
  • Event definitions 186 contain definitions of events (e.g., predefined sequences of sub-events), for example, event 1 (187-1), event 2 (187-2), and others.
  • sub-events in an event (187) include, for example, touch begin, touch end, touch movement, touch cancellation, and multiple touching.
  • the definition for event 1 (187-1) is a double tap on a displayed object. The double tap, for example, comprises a first touch (touch begin) on the displayed object for a predetermined phase, a first liftoff (touch end) for a predetermined phase, a second touch (touch begin) on the displayed object for a predetermined phase, and a second liftoff (touch end) for a predetermined phase.
  • the definition for event 2 is a dragging on a displayed object.
  • the dragging for example, comprises a touch (or contact) on the displayed object for a predetermined phase, a movement of the touch across touch-sensitive display 112, and liftoff of the touch (touch end).
  • the event also includes information for one or more associated event handlers 190.
  • event definition 187 includes a definition of an event for a respective user-interface object.
  • event comparator 184 performs a hit test to determine which user-interface object is associated with a sub-event.
  • event comparator 184 performs a hit test to determine which of the three user-interface objects is associated with the touch (sub- event). If each displayed object is associated with a respective event handler 190, the event comparator uses the result of the hit test to determine which event handler 190 should be activated. For example, event comparator 184 selects an event handler associated with the sub- event and the object triggering the hit test.
  • the definition for a respective event (187) also includes delayed actions that delay delivery of the event information until after it has been determined whether the sequence of sub-events does or does not correspond to the event recognizer’s event type.
  • a respective event recognizer 180 determines that the series of sub-events do not match any of the events in event definitions 186, the respective event recognizer 180 enters an event impossible, event failed, or event ended state, after which it disregards subsequent sub-events of the touch-based gesture. In this situation, other event recognizers, if any, that remain active for the hit view continue to track and process sub-events of an ongoing touch-based gesture.
  • a respective event recognizer 180 includes metadata 183 with configurable properties, flags, and/or lists that indicate how the event delivery system should perform sub-event delivery to actively involved event recognizers.
  • metadata 183 includes configurable properties, flags, and/or lists that indicate how event recognizers interact, or are enabled to interact, with one another.
  • metadata 183 includes configurable properties, flags, and/or lists that indicate whether sub- events are delivered to varying levels in the view or programmatic hierarchy.
  • a respective event recognizer 180 activates event handler 190 associated with an event when one or more particular sub-events of an event are recognized.
  • a respective event recognizer 180 delivers event information associated with the event to event handler 190. Activating an event handler 190 is distinct from sending (and deferred sending) sub-events to a respective hit view.
  • event recognizer 180 throws a flag associated with the recognized event, and event handler 190 associated with the flag catches the flag and performs a predefined process.
  • event delivery instructions 188 include sub-event delivery instructions that deliver event information about a sub-event without activating an event handler. Instead, the sub-event delivery instructions deliver event information to event handlers associated with the series of sub-events or to actively involved views.
  • Event handlers associated with the series of sub-events or with actively involved views receive the event information and perform a predetermined process.
  • data updater 176 creates and updates data used in application 136-1. For example, data updater 176 updates the telephone number used in contacts module 137, or stores a video file used in video player module.
  • object updater 177 creates and updates objects used in application 136-1. For example, object updater 177 creates a new user-interface object or updates the position of a user-interface object.
  • GUI updater 178 updates the GUI. For example, GUI updater 178 prepares display information and sends it to graphics module 132 for display on a touch-sensitive display.
  • event handler(s) 190 includes or has access to data updater 176, object updater 177, and GUI updater 178.
  • data updater 176, object updater 177, and GUI updater 178 are included in a single module of a respective application 136-1 or application view 191. In other embodiments, they are included in two or more software modules.
  • event handler(s) 190 includes or has access to data updater 176, object updater 177, and GUI updater 178.
  • data updater 176, object updater 177, and GUI updater 178 are included in a single module of a respective application 136-1 or application view 191. In other embodiments, they are included in two or more software modules.
  • event handler(s) 190 includes or has access to data updater 176, object updater 177, and GUI updater 178.
  • data updater 176, object updater 177, and GUI updater 178 are included in a single module of a respective application 136-1 or application view 191. In other embodiments
  • FIG.2 illustrates a portable multifunction device 100 having a touch screen 112 in accordance with some embodiments.
  • the touch screen optionally displays one or more graphics within user interface (UI) 200.
  • UI user interface
  • a user is enabled to select one or more of the graphics by making a gesture on the graphics, for example, with one or more fingers 202 (not drawn to scale in the figure) or one or more styluses 203 (not drawn to scale in the figure).
  • selection of one or more graphics occurs when the user breaks contact with the one or more graphics.
  • the gesture optionally includes one or more taps, one or more swipes (from left to right, right to left, upward and/or downward), and/or a rolling of a finger (from right to left, left to right, upward and/or downward) that has made contact with device 100.
  • inadvertent contact with a graphic does not select the graphic.
  • a swipe gesture that sweeps over an application icon optionally does not select the corresponding application when the gesture corresponding to selection is a tap.
  • stylus 203 is an active device and includes one or more electronic circuitry.
  • stylus 203 includes one or more sensors, and one or more communication circuitry (such as communication module 128 and/or RF circuitry 108).
  • stylus 203 includes one or more processors and power systems (e.g., similar to power system 162).
  • stylus 203 includes an accelerometer (such as accelerometer 168), magnetometer, and/or gyroscope that is able to determine the position, angle, location, and/or other physical characteristics of stylus 203 (e.g., such as whether the stylus is placed down, angled toward or away from a device, and/or near or far from a device).
  • stylus 203 is in communication with an electronic device (e.g., via communication circuitry, over a wireless communication protocol such as Bluetooth) and transmits sensor data to the electronic device.
  • stylus 203 is able to determine (e.g., via the accelerometer or other sensors) whether the user is holding the device.
  • stylus 203 can accept tap inputs (e.g., single tap or double tap) on stylus 203 (e.g., received by the accelerometer or other sensors) from the user and interpret the input as a command or request to perform a function or change to a different input mode.
  • Device 100 optionally also include one or more physical buttons, such as “home” or menu button 204.
  • menu button 204 is, optionally, used to navigate to any application 136 in a set of applications that are, optionally, executed on device 100.
  • the menu button is implemented as a soft key in a GUI displayed on touch screen 112.
  • device 100 includes touch screen 112, menu button 204, push button 206 for powering the device on/off and locking the device, volume adjustment button(s) 208, subscriber identity module (SIM) card slot 210, headset jack 212, and docking/charging external port 124.
  • SIM subscriber identity module
  • Push button 206 is, optionally, used to turn the power on/off on the device by depressing the button and holding the button in the depressed state for a predefined time interval; to lock the device by depressing the button and releasing the button before the predefined time interval has elapsed; and/or to unlock the device or initiate an unlock process.
  • device 100 also accepts verbal input for activation or deactivation of some functions through microphone 113.
  • Device 100 also, optionally, includes one or more contact intensity sensors 165 for detecting intensity of contacts on touch screen 112 and/or one or more tactile output generators 167 for generating tactile outputs for a user of device 100.
  • FIG.3 is a block diagram of an exemplary multifunction device with a display and a touch-sensitive surface in accordance with some embodiments.
  • Device 300 need not be portable.
  • device 300 is a laptop computer, a desktop computer, a tablet computer, a multimedia player device, a navigation device, an educational device (such as a child’s learning toy), a gaming system, or a control device (e.g., a home or industrial controller).
  • Device 300 typically includes one or more processing units (CPUs) 310, one or more network or other communications interfaces 360, memory 370, and one or more communication buses 320 for interconnecting these components.
  • CPUs processing units
  • Communication buses 320 optionally include circuitry (sometimes called a chipset) that interconnects and controls communications between system components.
  • Device 300 includes input/output (I/O) interface 330 comprising display 340, which is typically a touch screen display.
  • I/O interface 330 also optionally includes a keyboard and/or mouse (or other pointing device) 350 and touchpad 355, tactile output generator 357 for generating tactile outputs on device 300 (e.g., similar to tactile output generator(s) 167 described above with reference to FIG.1A), sensors 359 (e.g., optical, acceleration, proximity, touch- sensitive, and/or contact intensity sensors similar to contact intensity sensor(s) 165 described above with reference to FIG.1A).
  • sensors 359 e.g., optical, acceleration, proximity, touch- sensitive, and/or contact intensity sensors similar to contact intensity sensor(s) 165 described above with reference to FIG.1A).
  • Memory 370 includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid state memory devices; and optionally includes non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid state storage devices. Memory 370 optionally includes one or more storage devices remotely located from CPU(s) 310. In some embodiments, memory 370 stores programs, modules, and data structures analogous to the programs, modules, and data structures stored in memory 102 of portable multifunction device 100 (FIG.1A), or a subset thereof. Furthermore, memory 370 optionally stores additional programs, modules, and data structures not present in memory 102 of portable multifunction device 100.
  • memory 370 of device 300 optionally stores drawing module 380, presentation module 382, word processing module 384, website creation module 386, disk authoring module 388, and/or spreadsheet module 390, while memory 102 of portable multifunction device 100 (FIG.1A) optionally does not store these modules.
  • FIG.3 Each of the above-identified elements in FIG.3 is, optionally, stored in one or more of the previously mentioned memory devices.
  • Each of the above-identified modules corresponds to a set of instructions for performing a function described above.
  • the above- identified modules or programs (e.g., sets of instructions) need not be implemented as separate software programs, procedures, or modules, and thus various subsets of these modules are, optionally, combined or otherwise rearranged in various embodiments.
  • memory 370 optionally stores a subset of the modules and data structures identified above. Furthermore, memory 370 optionally stores additional modules and data structures not described above. [0125] Attention is now directed towards embodiments of user interfaces that are, optionally, implemented on, for example, portable multifunction device 100. [0126] FIG.4A illustrates an exemplary user interface for a menu of applications on portable multifunction device 100 in accordance with some embodiments. Similar user interfaces are, optionally, implemented on device 300.
  • user interface 400 includes the following elements, or a subset or superset thereof: ⁇ Signal strength indicator(s) 402 for wireless communication(s), such as cellular and Wi- Fi signals; ⁇ Time 404; ⁇ Bluetooth indicator 405; ⁇ Battery status indicator 406; ⁇ Tray 408 with icons for frequently used applications, such as: o Icon 416 for telephone module 138, labeled “Phone,” which optionally includes an indicator 414 of the number of missed calls or voicemail messages; o Icon 418 for e-mail client module 140, labeled “Mail,” which optionally includes an indicator 410 of the number of unread e-mails; o Icon 420 for browser module 147, labeled “Browser;” and o Icon 422 for video and music player module 152, also referred to as iPod (trademark of Apple Inc.) module 152, labeled “iPod;” and ⁇ Icons for other applications, such as: o Icon 424 for IM module 141,
  • FIG.4B illustrates an exemplary user interface on a device (e.g., device 300, FIG. 3) with a touch-sensitive surface 451 (e.g., a tablet or touchpad 355, FIG.3) that is separate from the display 450 (e.g., touch screen display 112).
  • a device e.g., device 300, FIG. 3
  • a touch-sensitive surface 451 e.g., a tablet or touchpad 355, FIG.3
  • Device 300 also, optionally, includes one or more contact intensity sensors (e.g., one or more of sensors 359) for detecting intensity of contacts on touch-sensitive surface 451 and/or one or more tactile output generators 357 for generating tactile outputs for a user of device 300.
  • contact intensity sensors e.g., one or more of sensors 359
  • tactile output generators 357 for generating tactile outputs for a user of device 300.
  • the touch-sensitive surface (e.g., 451 in FIG.4B) has a primary axis (e.g., 452 in FIG.4B) that corresponds to a primary axis (e.g., 453 in FIG.4B) on the display (e.g., 450).
  • the device detects contacts (e.g., 460 and 462 in FIG.4B) with the touch-sensitive surface 451 at locations that correspond to respective locations on the display (e.g., in FIG.4B, 460 corresponds to 468 and 462 corresponds to 470).
  • user inputs e.g., contacts 460 and 462, and movements thereof
  • the device on the touch-sensitive surface e.g., 451 in FIG.4B
  • the device on the touch-sensitive surface e.g., 451 in FIG.4B
  • the device on the touch-sensitive surface e.g., 451 in FIG.4B
  • the device on the touch-sensitive surface e.g., 451 in FIG.4B
  • the device e.g., 450 in FIG.4B
  • similar methods are, optionally, used for other user interfaces described herein.
  • finger inputs e.g., finger contacts, finger tap gestures, finger swipe gestures
  • one or more of the finger inputs are replaced with input from another input device (e.g., a mouse-based input or stylus input).
  • a swipe gesture is, optionally, replaced with a mouse click (e.g., instead of a contact) followed by movement of the cursor along the path of the swipe (e.g., instead of movement of the contact).
  • FIG.5A illustrates exemplary personal electronic device 500.
  • Device 500 includes body 502.
  • device 500 can include some or all of the features described with respect to devices 100 and 300 (e.g., FIGS.1A-4B).
  • device 500 has touch-sensitive display screen 504, hereafter touch screen 504.
  • device 500 has a display and a touch-sensitive surface.
  • touch screen 504 (or the touch-sensitive surface) optionally includes one or more intensity sensors for detecting intensity of contacts (e.g., touches) being applied.
  • the one or more intensity sensors of touch screen 504 (or the touch-sensitive surface) can provide output data that represents the intensity of touches.
  • the user interface of device 500 can respond to touches based on their intensity, meaning that touches of different intensities can invoke different user interface operations on device 500.
  • Exemplary techniques for detecting and processing touch intensity are found, for example, in related applications: International Patent Application Serial No.
  • device 500 has one or more input mechanisms 506 and 508.
  • Input mechanisms 506 and 508, if included, can be physical. Examples of physical input mechanisms include push buttons and rotatable mechanisms.
  • device 500 has one or more attachment mechanisms. Such attachment mechanisms, if included, can permit attachment of device 500 with, for example, hats, eyewear, earrings, necklaces, shirts, jackets, bracelets, watch straps, chains, trousers, belts, shoes, purses, backpacks, and so forth. These attachment mechanisms permit device 500 to be worn by a user.
  • FIG.5B depicts exemplary personal electronic device 500.
  • device 500 can include some or all of the components described with respect to FIGS.1A, 1B, and 3.
  • Device 500 has bus 512 that operatively couples I/O section 514 with one or more computer processors 516 and memory 518.
  • I/O section 514 can be connected to display 504, which can have touch-sensitive component 522 and, optionally, intensity sensor 524 (e.g., contact intensity sensor).
  • I/O section 514 can be connected with communication unit 530 for receiving application and operating system data, using Wi-Fi, Bluetooth, near field communication (NFC), cellular, and/or other wireless communication techniques.
  • Device 500 can include input mechanisms 506 and/or 508.
  • Input mechanism 506 is, optionally, a rotatable input device or a depressible and rotatable input device, for example.
  • Input mechanism 508 is, optionally, a button, in some examples. [0135]
  • Input mechanism 508 is, optionally, a microphone, in some examples.
  • Personal electronic device 500 optionally includes various sensors, such as GPS sensor 532, accelerometer 534, directional sensor 540 (e.g., compass), gyroscope 536, motion sensor 538, and/or a combination thereof, all of which can be operatively connected to I/O section 514.
  • Memory 518 of personal electronic device 500 can include one or more non- transitory computer-readable storage mediums, for storing computer-executable instructions, which, when executed by one or more computer processors 516, for example, can cause the computer processors to perform the techniques described below, including process 700, 900, 1100 and 1300 (Figs.7, 9, 11 and 13).
  • a computer-readable storage medium can be any medium that can tangibly contain or store computer-executable instructions for use by or in connection with the instruction execution system, apparatus, or device.
  • the storage medium is a transitory computer-readable storage medium.
  • the storage medium is a non-transitory computer-readable storage medium.
  • the non-transitory computer- readable storage medium can include, but is not limited to, magnetic, optical, and/or semiconductor storages. Examples of such storage include magnetic disks, optical discs based on CD, DVD, or Blu-ray technologies, as well as persistent solid-state memory such as flash, solid-state drives, and the like.
  • Personal electronic device 500 is not limited to the components and configuration of FIG.5B, but can include other or additional components in multiple configurations.
  • system or computer readable medium contains instructions for performing the contingent operations based on the satisfaction of the corresponding one or more conditions and thus is capable of determining whether the contingency has or has not been satisfied without explicitly repeating steps of a method until all of the conditions upon which steps in the method are contingent have been met.
  • a system or computer readable storage medium can repeat the steps of a method as many times as are needed to ensure that all of the contingent steps have been performed.
  • the term “affordance” refers to a user-interactive graphical user interface object that is, optionally, displayed on the display screen of devices 100, 300, and/or 500 (FIGS.1A, 3, and 5A-5B).
  • an image e.g., icon
  • a button e.g., button
  • text e.g., hyperlink
  • focus selector refers to an input element that indicates a current part of a user interface with which a user is interacting.
  • the cursor acts as a “focus selector” so that when an input (e.g., a press input) is detected on a touch-sensitive surface (e.g., touchpad 355 in FIG.3 or touch-sensitive surface 451 in FIG.4B) while the cursor is over a particular user interface element (e.g., a button, window, slider, or other user interface element), the particular user interface element is adjusted in accordance with the detected input.
  • a touch-sensitive surface e.g., touchpad 355 in FIG.3 or touch-sensitive surface 451 in FIG.4B
  • a particular user interface element e.g., a button, window, slider, or other user interface element
  • a detected contact on the touch screen acts as a “focus selector” so that when an input (e.g., a press input by the contact) is detected on the touch screen display at a location of a particular user interface element (e.g., a button, window, slider, or other user interface element), the particular user interface element is adjusted in accordance with the detected input.
  • a particular user interface element e.g., a button, window, slider, or other user interface element
  • focus is moved from one region of a user interface to another region of the user interface without corresponding movement of a cursor or movement of a contact on a touch screen display (e.g., by using a tab key or arrow keys to move focus from one button to another button); in these implementations, the focus selector moves in accordance with movement of focus between different regions of the user interface.
  • the focus selector is generally the user interface element (or contact on a touch screen display) that is controlled by the user so as to communicate the user’s intended interaction with the user interface (e.g., by indicating, to the device, the element of the user interface with which the user is intending to interact).
  • the location of a focus selector e.g., a cursor, a contact, or a selection box
  • a press input is detected on the touch-sensitive surface (e.g., a touchpad or touch screen) will indicate that the user is intending to activate the respective button (as opposed to other user interface elements shown on a display of the device).
  • the term “characteristic intensity” of a contact refers to a characteristic of the contact based on one or more intensities of the contact. In some embodiments, the characteristic intensity is based on multiple intensity samples.
  • the characteristic intensity is, optionally, based on a predefined number of intensity samples, or a set of intensity samples collected during a predetermined time period (e.g., 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10 seconds) relative to a predefined event (e.g., after detecting the contact, prior to detecting liftoff of the contact, before or after detecting a start of movement of the contact, prior to detecting an end of the contact, before or after detecting an increase in intensity of the contact, and/or before or after detecting a decrease in intensity of the contact).
  • a predefined time period e.g., 0.05, 0.1, 0.2, 0.5, 1, 2, 5, 10 seconds
  • a characteristic intensity of a contact is, optionally, based on one or more of: a maximum value of the intensities of the contact, a mean value of the intensities of the contact, an average value of the intensities of the contact, a top 10 percentile value of the intensities of the contact, a value at the half maximum of the intensities of the contact, a value at the 90 percent maximum of the intensities of the contact, or the like.
  • the duration of the contact is used in determining the characteristic intensity (e.g., when the characteristic intensity is an average of the intensity of the contact over time).
  • the characteristic intensity is compared to a set of one or more intensity thresholds to determine whether an operation has been performed by a user.
  • the set of one or more intensity thresholds optionally includes a first intensity threshold and a second intensity threshold.
  • a contact with a characteristic intensity that does not exceed the first threshold results in a first operation
  • a contact with a characteristic intensity that exceeds the first intensity threshold and does not exceed the second intensity threshold results in a second operation
  • a contact with a characteristic intensity that exceeds the second threshold results in a third operation.
  • a comparison between the characteristic intensity and one or more thresholds is used to determine whether or not to perform one or more operations (e.g., whether to perform a respective operation or forgo performing the respective operation), rather than being used to determine whether to perform a first operation or a second operation.
  • FIG.5C illustrates detecting a plurality of contacts 552A-552E on touch-sensitive display screen 504 with a plurality of intensity sensors 524A-524D.
  • FIG.5C additionally includes intensity diagrams that show the current intensity measurements of the intensity sensors 524A-524D relative to units of intensity.
  • the intensity measurements of intensity sensors 524A and 524D are each 9 units of intensity
  • the intensity measurements of intensity sensors 524B and 524C are each 7 units of intensity.
  • an aggregate intensity is the sum of the intensity measurements of the plurality of intensity sensors 524A-524D, which in this example is 32 intensity units.
  • each contact is assigned a respective intensity that is a portion of the aggregate intensity.
  • FIG.5D illustrates assigning the aggregate intensity to contacts 552A-552E based on their distance from the center of force 554.
  • each of contacts 552A, 552B, and 552E are assigned an intensity of contact of 8 intensity units of the aggregate intensity
  • each of contacts 552C and 552D are assigned an intensity of contact of 4 intensity units of the aggregate intensity.
  • Ij A ⁇ (Dj/ ⁇ Di)
  • Dj is the distance of the respective contact j to the center of force
  • the operations described with reference to FIGS.5C-5D can be performed using an electronic device similar or identical to device 100, 300, or 500.
  • a characteristic intensity of a contact is based on one or more intensities of the contact.
  • the intensity sensors are used to determine a single characteristic intensity (e.g., a single characteristic intensity of a single contact). It should be noted that the intensity diagrams are not part of a displayed user interface, but are included in FIGS.5C-5D to aid the reader. [0142] In some embodiments, a portion of a gesture is identified for purposes of determining a characteristic intensity. For example, a touch-sensitive surface optionally receives a continuous swipe contact transitioning from a start location and reaching an end location, at which point the intensity of the contact increases.
  • the characteristic intensity of the contact at the end location is, optionally, based on only a portion of the continuous swipe contact, and not the entire swipe contact (e.g., only the portion of the swipe contact at the end location).
  • a smoothing algorithm is, optionally, applied to the intensities of the swipe contact prior to determining the characteristic intensity of the contact.
  • the smoothing algorithm optionally includes one or more of: an unweighted sliding-average smoothing algorithm, a triangular smoothing algorithm, a median filter smoothing algorithm, and/or an exponential smoothing algorithm. In some circumstances, these smoothing algorithms eliminate narrow spikes or dips in the intensities of the swipe contact for purposes of determining a characteristic intensity.
  • the intensity of a contact on the touch-sensitive surface is, optionally, characterized relative to one or more intensity thresholds, such as a contact-detection intensity threshold, a light press intensity threshold, a deep press intensity threshold, and/or one or more other intensity thresholds.
  • the light press intensity threshold corresponds to an intensity at which the device will perform operations typically associated with clicking a button of a physical mouse or a trackpad.
  • the deep press intensity threshold corresponds to an intensity at which the device will perform operations that are different from operations typically associated with clicking a button of a physical mouse or a trackpad.
  • the device when a contact is detected with a characteristic intensity below the light press intensity threshold (e.g., and above a nominal contact-detection intensity threshold below which the contact is no longer detected), the device will move a focus selector in accordance with movement of the contact on the touch-sensitive surface without performing an operation associated with the light press intensity threshold or the deep press intensity threshold.
  • these intensity thresholds are consistent between different sets of user interface figures.
  • An increase of characteristic intensity of the contact from an intensity below the light press intensity threshold to an intensity between the light press intensity threshold and the deep press intensity threshold is sometimes referred to as a “light press” input.
  • An increase of characteristic intensity of the contact from an intensity below the deep press intensity threshold to an intensity above the deep press intensity threshold is sometimes referred to as a “deep press” input.
  • An increase of characteristic intensity of the contact from an intensity below the contact- detection intensity threshold to an intensity between the contact-detection intensity threshold and the light press intensity threshold is sometimes referred to as detecting the contact on the touch- surface.
  • a decrease of characteristic intensity of the contact from an intensity above the contact- detection intensity threshold to an intensity below the contact-detection intensity threshold is sometimes referred to as detecting liftoff of the contact from the touch-surface.
  • the contact-detection intensity threshold is zero. In some embodiments, the contact-detection intensity threshold is greater than zero.
  • one or more operations are performed in response to detecting a gesture that includes a respective press input or in response to detecting the respective press input performed with a respective contact (or a plurality of contacts), where the respective press input is detected based at least in part on detecting an increase in intensity of the contact (or plurality of contacts) above a press-input intensity threshold.
  • the respective operation is performed in response to detecting the increase in intensity of the respective contact above the press-input intensity threshold (e.g., a “down stroke” of the respective press input).
  • the press input includes an increase in intensity of the respective contact above the press-input intensity threshold and a subsequent decrease in intensity of the contact below the press-input intensity threshold, and the respective operation is performed in response to detecting the subsequent decrease in intensity of the respective contact below the press-input threshold (e.g., an “up stroke” of the respective press input).
  • FIGS.5E-5H illustrate detection of a gesture that includes a press input that corresponds to an increase in intensity of a contact 562 from an intensity below a light press intensity threshold (e.g., “ITL”) in FIG.5E, to an intensity above a deep press intensity threshold (e.g., “ITD”) in FIG.5H.
  • the gesture performed with contact 562 is detected on touch-sensitive surface 560 while cursor 576 is displayed over application icon 572B corresponding to App 2, on a displayed user interface 570 that includes application icons 572A-572D displayed in predefined region 574.
  • the gesture is detected on touch-sensitive display 504.
  • the intensity sensors detect the intensity of contacts on touch-sensitive surface 560.
  • the device determines that the intensity of contact 562 peaked above the deep press intensity threshold (e.g., “ITD”). Contact 562 is maintained on touch-sensitive surface 560.
  • reduced-scale representations 578A- 578C (e.g., thumbnails) of recently opened documents for App 2 are displayed, as shown in FIGS.5F-5H.
  • the intensity which is compared to the one or more intensity thresholds, is the characteristic intensity of a contact. It should be noted that the intensity diagram for contact 562 is not part of a displayed user interface, but is included in FIGS.5E-5H to aid the reader. [0147] In some embodiments, the display of representations 578A-578C includes an animation.
  • representation 578A is initially displayed in proximity of application icon 572B, as shown in FIG.5F. As the animation proceeds, representation 578A moves upward and representation 578B is displayed in proximity of application icon 572B, as shown in FIG. 5G. Then, representations 578A moves upward, 578B moves upward toward representation 578A, and representation 578C is displayed in proximity of application icon 572B, as shown in FIG.5H. Representations 578A-578C form an array above icon 572B.
  • the animation progresses in accordance with an intensity of contact 562, as shown in FIGS.5F- 5G, where the representations 578A-578C appear and move upwards as the intensity of contact 562 increases toward the deep press intensity threshold (e.g., “ITD”).
  • the intensity, on which the progress of the animation is based is the characteristic intensity of the contact.
  • the device employs intensity hysteresis to avoid accidental inputs sometimes termed “jitter,” where the device defines or selects a hysteresis intensity threshold with a predefined relationship to the press-input intensity threshold (e.g., the hysteresis intensity threshold is X intensity units lower than the press-input intensity threshold or the hysteresis intensity threshold is 75%, 90%, or some reasonable proportion of the press-input intensity threshold).
  • the hysteresis intensity threshold is X intensity units lower than the press-input intensity threshold or the hysteresis intensity threshold is 75%, 90%, or some reasonable proportion of the press-input intensity threshold.
  • the press input includes an increase in intensity of the respective contact above the press-input intensity threshold and a subsequent decrease in intensity of the contact below the hysteresis intensity threshold that corresponds to the press-input intensity threshold, and the respective operation is performed in response to detecting the subsequent decrease in intensity of the respective contact below the hysteresis intensity threshold (e.g., an “up stroke” of the respective press input).
  • the press input is detected only when the device detects an increase in intensity of the contact from an intensity at or below the hysteresis intensity threshold to an intensity at or above the press-input intensity threshold and, optionally, a subsequent decrease in intensity of the contact to an intensity at or below the hysteresis intensity, and the respective operation is performed in response to detecting the press input (e.g., the increase in intensity of the contact or the decrease in intensity of the contact, depending on the circumstances).
  • the descriptions of operations performed in response to a press input associated with a press-input intensity threshold or in response to a gesture including the press input are, optionally, triggered in response to detecting either: an increase in intensity of a contact above the press-input intensity threshold, an increase in intensity of a contact from an intensity below the hysteresis intensity threshold to an intensity above the press-input intensity threshold, a decrease in intensity of the contact below the press-input intensity threshold, and/or a decrease in intensity of the contact below the hysteresis intensity threshold corresponding to the press-input intensity threshold.
  • an “installed application” refers to a software application that has been downloaded onto an electronic device (e.g., devices 100, 300, and/or 500) and is ready to be launched (e.g., become opened) on the device.
  • a downloaded application becomes an installed application by way of an installation program that extracts program portions from a downloaded package and integrates the extracted portions with the operating system of the computer system.
  • the terms “open application” or “executing application” refer to a software application with retained state information (e.g., as part of device/global internal state 157 and/or application internal state 192).
  • An open or executing application is, optionally, any one of the following types of applications: ⁇ an active application, which is currently displayed on a display screen of the device that the application is being used on; ⁇ a background application (or background processes), which is not currently displayed, but one or more processes for the application are being processed by one or more processors; and ⁇ a suspended or hibernated application, which is not running, but has state information that is stored in memory (volatile and non-volatile, respectively) and that can be used to resume execution of the application.
  • the term “closed application” refers to software applications without retained state information (e.g., state information for closed applications is not stored in a memory of the device).
  • closing an application includes stopping and/or removing application processes for the application and removing state information for the application from the memory of the device.
  • opening a second application while in a first application does not close the first application.
  • the first application becomes a background application.
  • UI user interfaces
  • USER INTERFACES AND ASSOCIATED PROCESSES Customized Navigation Routes Users interact with electronic devices in many different manners, including using electronic devices to view and find geographic locations on a map. In some embodiments, a user can request directions from one geographic location to another geographic location.
  • Figs.6A-6FF illustrate exemplary ways in which an electronic device displays customized navigation routes in accordance with some embodiments of the disclosure. The embodiments in these figures are used to illustrate the processes described below, including the processes described with reference to Fig.7.
  • Figs.6A-6FF illustrate various examples of ways an electronic device is able to perform the processes described below with respect to Fig.7, it should be understood that these examples are not meant to be limiting, and the electronic device is able to perform one or more processes described below with reference to Fig. 7 in ways not expressly described with reference to Figs.6A-6FF.
  • Fig.6A illustrates electronic device 500 displaying user interface 600 (e.g., via a display device, via a display generation component, etc.).
  • user interface 600 is displayed via a display generation component.
  • the display generation component is a hardware component (e.g., including electrical components) capable of receiving display data and displaying a user interface.
  • examples of a display generation component include a touch screen display (such as touch screen 504), a monitor, a television, a projector, an integrated, discrete, or external display device, or any other suitable display device that is in communication with device 500.
  • user interface 600 is a user interface of a map application (e.g., an application in which a user is able to view geographic locations, search for locations, and/or request directions from one location to another).
  • the map application is an application installed on device 500.
  • the map application can present maps, routes, location metadata, and/or imagery (e.g., captured photos) associated with various geographical locations, points of interest, etc.
  • the map application can obtain map data that includes data defining maps, map objects, routes, points of interest, imagery, etc., from a navigation server.
  • the map data can be received as map tiles that include map data for geographical areas corresponding to the respective map tiles.
  • the map data can include, among other things, data defining roads and/or road segments, metadata for points of interest and other locations, three- dimensional models of the buildings, infrastructure, and other objects found at the various locations, and/or images captured at the various locations.
  • the map application can request from a navigation server through a network (e.g., local area network, cellular data network, wireless network, the Internet, wide area network, etc.) map data (e.g., map tiles) associated with locations that device 500 frequently visits.
  • a network e.g., local area network, cellular data network, wireless network, the Internet, wide area network, etc.
  • map data e.g., map tiles
  • the map application can store the map data in a map database.
  • the map application can use the map data stored in the map database and/or other map data received from device 500 to provide the map application features described herein (e.g., display of customized navigation routes).
  • the navigation server can be a software server configured to obtain, generate, and/or store map data.
  • the navigation server can obtain a lidar generated point cloud (e.g., points that define locations of surfaces of objects in the vicinity of an image capture location) for various locations included in the map data.
  • the navigation server can generate a three-dimensional model (e.g., three-dimensional mesh) for each of the various locations using the respective point clouds for the locations.
  • the navigation server can obtain images captured at the various locations (e.g., capture locations) and use the images to add texture to the three-dimensional model thereby generating a photorealistic three-dimensional image representing the corresponding location.
  • the captured images e.g., photographs, panorama photographs, etc.
  • the three-dimensional models and textures e.g., captured images, stretched images, images applied to the three-dimensional model, etc.
  • the navigation server can be configured to obtain, generate, and/or store other map data in the map database.
  • this determination can be performed by the navigation server or by a combination of device 500 and the navigation server, the results of which are provided to device 500 for display in a user interface via a display generation component of device 500.
  • user interface 600 includes a representation of a map.
  • user interface 600 includes representations (e.g., textual and/or graphical presentations) associated with particular geographic location, including representations of roads, landmarks, businesses, and/or buildings, etc.
  • a user is able to search for a respective place or address.
  • a user has performed a search for Destination 1.
  • user interface 600 in response to the search for Destination 1, includes representation 604 at the location on the map corresponding to the location of Destination 1, as shown in Fig.6A.
  • the map application searches through a map database for locations (e.g., places) that match the search criteria (e.g., for Destination 1).
  • the map application can send a request to a navigation server to cause the navigation server to search for locations that match the search criteria.
  • the map application can present a list of places that match the search criteria and/or the user may select one of the places to cause the place (e.g., address, point of interest, landmark, etc.) to be presented on user interface 600.
  • device 500 displays user interface 606 corresponding to Destination 1.
  • user interface 606 is displayed overlaid over user interface 600.
  • user interface 606 includes information associated with Destination 1.
  • user interface 606 includes textual indication 608, button 610, and graphic 612.
  • textual indication 608 includes the name of Destination 1 and/or the address of Destination 1.
  • button 610 is selectable to request and/or display navigation directions to Destination 1 (e.g., from the current location of the electronic device or from a respective location provided by a user).
  • graphic 612 includes an image associated with Destination 1 (e.g., an image of the location, an image of the view of Destination 1 from the street level, etc.).
  • user interface 606 includes button 614 that is selectable to dismiss user interface 606 (e.g., and optionally cease display of the search results). [0164] In Fig.6A, a user input 603a is received selecting button 610.
  • device 500 in response to the user input, displays one or more suggested routes to travel from the current location of device 500 (e.g., represented by location indicator 602) to Destination 1, as shown in Fig.6B.
  • device 500 displays suggested route 620-1 and suggested route 620-2.
  • suggested route 620-1 is the fastest route to Destination 1.
  • suggested route 620-2 is an alternative route to suggested route 620-1.
  • suggested route 620-1 and/or suggested route 620-2 are selected based on different criteria such as shortest route, fastest route, avoiding tolls, avoiding highways.
  • the suggested routes are selected while taking into consideration the current traffic conditions.
  • device 500 displays user interface 607, as shown in Fig.6B.
  • user interface 607 includes information for navigating to Destination 1.
  • user interface 607 includes textual indication 609, listing 616-1, and listing 616-2.
  • textual indication 609 includes an indication that the suggested routes are for travel to Destination 1 and an indication that the suggested routes are for travel from “My Location” to Destination 1.
  • listing 616-1 corresponds to suggested route 620-1 and includes a description that suggested route 620-1 is estimated to take 50 minutes to travel, that suggested route 620-1 is 43.8 miles in length, and that suggested route 620-1 is the fastest route (e.g., by time, optionally including current traffic conditions).
  • listing 616-2 corresponds to suggested route 620-1 and includes a description that suggested route 620-2 is estimated to take 57 minutes to travel, that suggested route 620-2 is 44.5 miles in length, and that suggested route 620-2 is an alternative route (e.g., alternative to suggested route 620-1).
  • listing 616-1 and listing 616-2 include button 618-1 and button 618-2, respectively, that are selectable to begin navigation along the respective suggested route. In some embodiments, listing 616-1 and listing 616-2 are selectable to display more information about the respective route, as will be described in more detail below.
  • Fig.6B illustrates two suggested routes being displayed, device 500 may display only one suggested route or may display more than two suggested routes.
  • a contact 603b is received on user interface 607.
  • an upward swipe 603c of contact 603b on user interface 607 is detected (e.g., an upward swipe from contact 603b in Fig.6B).
  • expanded user interface 607 in response to upward swipe 603c, is expanded upwards in accordance with the upward swipe gesture, as shown in Fig.6C.
  • expanded user interface 607 includes options for selecting one or more vehicles for which to provide customized suggested routes.
  • expanded user interface 607 includes vehicle list 622.
  • vehicle list 622 includes vehicle option 624-1, vehicle option 624-2, and no vehicle option 624-3.
  • vehicle option 624-1 corresponds to a first vehicle that has been registered with (e.g., added to) the map application and vehicle option 624-2 corresponds to a second vehicle that has been registered with the map application.
  • vehicle 1 is a gas vehicle and vehicle 2 is an electric vehicle.
  • the no vehicle option 624-3 corresponds to no specific vehicle and selection of vehicle option 624-3 causes the map application to suggest routes that are selected without consideration of the characteristics of a specific vehicle (e.g., such as a type of fuel for a particular vehicle or the fuel and/or charge level of a particular vehicle), such as described above with respect to Fig.6B.
  • vehicle option 624-1 includes a textual description 626-1 of Gas Vehicle 1 (e.g., the name of the vehicle, the make, the model, etc.).
  • vehicle option 624-1 includes indication 628-1 of how much fuel (e.g., for a gasoline vehicle) and/or charge (e.g., for an electric vehicle) the vehicle current has.
  • the map application receives the current fuel and/or charge information from another application or a server, as will be described in further detail below with respect to method 900.
  • vehicle option 624-2 includes a textual description 626-2 of Electric Vehicle 2 (e.g., the name of the vehicle, the make, the model, etc.).
  • vehicle option 624-2 includes indication 628-2 of how much fuel (e.g., for a gasoline vehicle) and/or charge (e.g., for an electric vehicle) the vehicle current has.
  • vehicle list 622 will include more or fewer vehicles, respectively.
  • icon 627 e.g., a check mark
  • the currently selected option in vehicle list 622 is the no vehicle option 624-3, and thus no vehicle is currently selected.
  • Fig.6C illustrates two vehicles (Vehicle 1 as a gasoline vehicle, and Vehicle 2 as an electric vehicle) being registered with the map application, more or fewer vehicles can be registered with the map application.
  • vehicle list 622 includes no vehicles and only includes the no vehicle option 626-3 (or optionally vehicle list 622 is not included on user interface 607).
  • vehicle listing 622 can have one or more vehicles corresponding to the vehicles that have been added.
  • vehicle listing 622 can have one vehicle listing and the no vehicle listing 626-3.
  • any of the vehicles in vehicle listing 622 can be a vehicle of any fuel type (e.g., gasoline vehicle, hybrid vehicle, plug-in hybrid vehicle, hydrogen vehicle, fuel cell vehicle, electric vehicle, solar vehicle, etc.).
  • Figs.6D-6V illustrate embodiments in which suggested routes are displayed based on characteristics of a selected vehicle.
  • the map application or optionally the navigation server described above with which the map application is in communication
  • the map application is able to determine whether a selected vehicle requires a stop to recharge or refuel in order to reach a destination.
  • Gasoline Vehicle 1 and Electric Vehicle 2 are not limited to only the type of vehicle for which the features were described (e.g., the features described for Gasoline Vehicle 1 are not limited only to gasoline vehicles, and the features described for Electric Vehicle 2 are not limited to only electric vehicles), and any or all of the features described for Gasoline Vehicle 1 can be applied to Electric Vehicle 2 and vice versa. Additionally, the features described for either Gasoline Vehicle 1 and Electric Vehicle 2 can be applied to any type of vehicle with any fuel type (e.g., unleaded gasoline vehicle, diesel gasoline vehicle, hybrid vehicle, plug-in hybrid vehicle, electric vehicle, fuel cell vehicle, hydrogen vehicle, etc.).
  • fuel type e.g., unleaded gasoline vehicle, diesel gasoline vehicle, hybrid vehicle, plug-in hybrid vehicle, electric vehicle, fuel cell vehicle, hydrogen vehicle, etc.
  • a user input 603d is received selecting vehicle option 624-1 corresponding to Gas Vehicle 1.
  • Gas Vehicle 1 in response to user input 603d, Gas Vehicle 1 becomes the selected vehicle, as shown in Fig.6E.
  • the suggested routes are updated to be customized for Gas Vehicle 1 (optionally if suggested routes were not provided by the map application when the user selected Gas Vehicle 1, then no suggested routes are updated).
  • a customized route for a vehicle is selected based on at least some of the characteristics of the selected vehicle (e.g., one characteristic, two characteristics, etc.).
  • suggested route 620-2 and suggested route 620-3 are selected based on a characteristic of Gas Vehicle 1.
  • the suggested routes are selected based on the current gas level of Gas Vehicle 1.
  • the suggested routes are selected based on the estimated driving range of Gas Vehicle 1 (e.g., the distance that Gas Vehicle 1 can travel with the current amount of fuel without refueling).
  • suggested route 620-3 is the primary recommended route (e.g., the first listed route and displayed with a prioritized visual characterization) and includes suggested stop 632-1.
  • suggested stop 632-1 is an icon that represents a gasoline station and indicates that a stop to refuel Gas Vehicle 1 is recommended and/or required to reach the destination. In some embodiments, suggested stop 632-1 is placed at a location on suggested route 620-3 corresponding to the location of the respective gasoline station. In some embodiments, a determination that a refueling stop should be suggested is based on the estimated driving range of Gas Vehicle 1. In some embodiments, if the estimated driving range of Gas Vehicle 1 is not enough to reach the destination, then a suggested stop is recommended. In some embodiments, if Gas Vehicle 1 will reach the destination with less than a threshold amount of fuel (e.g., less than 5%, 10%, 15%, 20%, etc.
  • a threshold amount of fuel e.g., less than 5%, 10%, 15%, 20%, etc.
  • listing 616-1 corresponding to suggested route 620-3 includes indication 630-1 that indicates that suggested route 620-3 includes one stop in Echo Park (e.g., the name of the region at which the gas station is located).
  • listing 616-2 corresponding to suggested route 620-2 includes indication 630-2 that indicates that suggested route 620-2 includes one stop in Pleasantville.
  • listing 616-1 and listing 616-2 includes an indication of the estimated amount of time to travel along the respective suggested route.
  • the estimated amount of time includes the estimated amount of time to refuel the vehicle to the suggested level.
  • suggested route 620-2 does not include a representation or icon of a suggested stop even though suggested route 620-2 does include a suggested stop.
  • only the first listed (e.g., most recommended, or the route that is currently selected or highlighted) suggested stop includes icons of suggested stops and other suggested routes do not include an icon of suggested stops even if the suggested route includes suggested stops (e.g., any or all of the other suggested stops).
  • all displayed suggested routes include an icon or indication of suggested stops (e.g., and not just the first suggested route).
  • one or more of the customized suggested routes is the same as the non-customized suggested routes.
  • suggested route 620-2 in Fig.6E is the same as suggested route 620-3 in Fig.6B (e.g., optionally except that suggested route 620-2 in Fig.6E includes a suggested stop).
  • suggested route 620-3 is a route that would not otherwise be suggested when no vehicle is selected (e.g., as in Fig.6B).
  • user input 603e is received selecting listing 616-1 corresponding to suggested route 620-3.
  • device 500 displays user interface 634, as shown in Fig.6F.
  • user interface 634 includes one or more step-by-step directions for travelling from the current location of device 500 to Destination 1 via suggested route 620-3.
  • user interface 634 includes step 636- 1 to step 636-7 for travelling from the starting location to the destination location.
  • one or more of the steps includes an indication of an amount of fuel and/or charge that the vehicle will or should have when the vehicle reaches or is following the respective step.
  • step 636-1 corresponding to the starting location e.g., the starting step
  • indication 638-1 includes an indication of the current amount of gas (e.g., because step 636-1 is the first step).
  • step 636-4 corresponding to the suggested stop includes an indication 638-2 of the recommended amount of fuel to fill Gas Vehicle 1 up to in order to reach the destination (optionally to reach the destination with the threshold amount of fuel or remaining driving range).
  • step 636-7 corresponding to the arrival step at the destination includes indication 638-3 that indicates the estimated amount of fuel that Gas Vehicle 1 will have upon arriving at the destination (e.g., 5/16 of a tank).
  • any of steps 636-1 to 636-7 can include an indication of an estimated amount of fuel when arriving at or following the respective step.
  • user input 603f is received selecting the “Done” button.
  • user interface 634 is dismissed (e.g., ceased to be displayed), as shown in Fig.6G.
  • a contact 603g is received on user interface 607.
  • Fig.6H an upward swipe 603h of contact 603g on user interface 607 is detected (e.g., an upward swipe from contact 603g in Fig.6G) causing display of expanded user interface 607.
  • a user input 603i is received selecting listing 626-2 corresponding to Electric Vehicle 2.
  • Electric Vehicle 2 becomes the selected vehicle, as shown in Fig.6J.
  • suggested routes are updated to be customized for Electric Vehicle 2.
  • user interface 600 includes suggested route 620-1 and suggested route 620-2.
  • suggested route 620-1 and suggested route 620-2 are the same routes suggested in Fig.6B because Electric Vehicle 2 has enough charge to reach the destination (e.g., 73% charge).
  • the suggested routes can optionally be the same suggested routes as when device 500 does not take into account charge status (e.g., when device 500 suggests routes when no vehicle is selected).
  • Fig.6K illustrates an embodiment in which Electric Vehicle 2 does not have enough charge to reach the destination (e.g., 23% charge).
  • user interface 600 includes suggested route 620-4 and suggested route 620-5.
  • suggested route 620-4 includes suggested stop 632-2 corresponding to a recommended stop to recharge Electric Vehicle 2 at an electric vehicle charging station.
  • suggested stop 632-2 is recommended because Electric Vehicle 2 does not have enough charge to reach the destination (or optionally will not have enough charge to reach the destination with a threshold amount of remaining charge or remaining driving range).
  • suggested stop 632-2 is selected based on the charging station network that is compatible with Electric Vehicle 2.
  • suggested stop 632-2 in Fig.6K is an electric vehicle charging station based on the fact that Electric Vehicle 2 requires electric charge for travel, but the suggested stop can be any type of refilling or recharging station based on the type of vehicle for which suggested stops are suggested (e.g., gasoline vehicle, hydrogen vehicle, E85 vehicle, diesel vehicle, etc.).
  • suggested route 620-4 is a different route than suggested route 620-1 and suggested route 620-2 because device 500 has determined that a recharging stop is required.
  • suggested route 620-4 navigates the user to a suggested recharging stop before navigating the user to the destination.
  • suggested route 620-4 is different than suggested route 620-3 because Electric Vehicle 2 requires an electric vehicle recharging stop rather than a gasoline station stop.
  • device 500 is able to take into account the charge status of Electric Vehicle 2 as well as the type of stop required based on the fuel type of Electric Vehicle 2 (e.g., electricity rather than gasoline).
  • suggested route 620-5 is different from suggested route 620-1, suggested route 620-2 and suggested route 620-3 because it is an alternative route that also includes a stop at an electric vehicle charging station.
  • any of the suggested routes for Electric Vehicle 2 can have a similar route as any of the suggested routes discussed above for Gas Vehicle 1 or when no vehicle is selected, but optionally include a stop at an electric vehicle charging station, for example, if a compatible electric vehicle charging station happens to be along one of the routes that otherwise would have been suggested to the user for Electric Vehicle 2.
  • listing 616-1 corresponding to suggested route 620-4 includes indication 630-1 that indicates that suggested route 620-3 includes one stop in Echo Park (e.g., the name of the region at which the charging station is located).
  • listing 616-2 corresponding to suggested route 620-5 includes indication 630-2 that indicates that suggested route 620-5 includes one stop in Silent Hill.
  • suggested route 620-5 does not include a representation or icon of a suggested stop even though suggested route 620-5 does include a suggested stop.
  • only the first listed (e.g., most recommended route or the route that is currently selected or highlighted) suggested stop includes icons of suggested stops and other suggested routes do not include an icon of suggested stops even if the suggested route includes suggested stops (e.g., any or all of the other suggested stops).
  • all displayed suggested routes include an icon or indication of suggested stops (e.g., and not just the first suggested route).
  • the indication (e.g., icon) of the suggested stop 632-2 is a representation of an electric vehicle charging station and is a different icon than suggested stop 632-1 shown in Fig.6G that is a representation of a gas station.
  • the icon representing a suggested stop along a route is the same regardless of whether the suggested stop is an electric vehicle charging station or a gasoline station.
  • user input 603k is an input that selects listing 616-1 corresponding to suggested route 620-4.
  • device 500 displays user interface 634, as shown in Fig.6L.
  • user interface 634 includes one or more step-by-step directions for travelling from the current location or a selected starting location of device 500 to Destination 1 via suggested route 620-4.
  • user interface 634 includes step 636-1 to step 636-6 for travelling from the starting location to the destination location.
  • one or more of the steps 636-1 to 636-6 include an indication of an amount of charge that Electric Vehicle 2 will or should have when the vehicle reaches the location of the respective step (e.g., if the vehicle is following the route as planned).
  • step 636-1 corresponding to the starting location includes indication 638-1 of the estimated amount of charge that Electric Vehicle 2 will have at the starting location.
  • indication 638-1 includes an indication of the current amount of charge (e.g., because step 636-1 is the first step).
  • step 636-4 corresponding to the suggested stop of FIG.6K includes an indication 638-2 of the recommended amount of charge to recharge Electric Vehicle 2 up to in order to reach the destination (optionally to reach the destination with the threshold amount of charge or remaining driving range).
  • step 636-6 corresponding to the arrival step at the destination includes indication 638-3 that indicates the estimated amount of charge that Electric Vehicle 2 will have upon arriving at the destination (e.g., 38% battery remaining). It is understood that more or fewer steps can include indications of an estimated amount of charge and any of steps 636-1 to 636-6 can include an indication of an estimated amount of charge when arriving at or following the respective step.
  • user input 603l is received selecting the “Done” button.
  • user interface 634 is dismissed (e.g., ceased to be displayed), as shown in Fig.6M.
  • a user input 603m is received selecting button 618- 1 for beginning navigation using suggested route 620-4.
  • device 500 in response to user input 603m, device 500 begins navigation mode and displays user interface 640, as shown in Fig.6N.
  • navigation mode includes displaying step-by-step and/or turn-by-turn directions to travel along a respective route.
  • the step-by-step and/or turn-by-turn directions are provided based on the location of the device to provide the user with live directions to reach the destination.
  • user interface 640 includes instructions 642 and instructions 644.
  • instructions 642 includes textual instructions corresponding to the currently displayed step.
  • instructions 642 instruct the user to begin driving on Main St.
  • instructions 644 provide additional instructions associated with the displayed step or provides a preview of the next step.
  • instructions 644 indicates that the next step is to turn left on Ocean Ave.
  • any of instructions 642 and/or 644 can include an icon representative of the step (e.g., a turn icon, a start icon, etc.).
  • instructions 644 is not displayed for certain steps or for all steps (e.g., if additional information is not necessary).
  • user interface 640 includes a representation of the map that includes the current position of device 500, illustrated by location indicator 646.
  • location indicator 646 indicates the current position of device 500 (e.g., is located on the representation of the map corresponding to the current location of device 500) and/or the orientation of device 500 (e.g., the arrow in location indicator 646 is facing in the direction of the orientation of device 500).
  • user interface 640 includes route 648 corresponding to suggested route 620-4.
  • the representation of the map is oriented such that the map is facing the direction that device 500 is facing. For example, in Fig. 6N, if device 500 is facing south, then the representation of the map is oriented such that south is upwards.
  • user interface 640 includes user interface 650 that is displayed overlaid over user interface 640.
  • user interface 650 provides general information of suggested route 620-4.
  • user interface 650 includes indication 652, indication 654, and button 656.
  • indication 652 displays the estimated time of arrival at the next stop (e.g., the suggested stop, the destination, or a user-selected stop along the suggested route).
  • indication 654 displays the estimated amount of charge that Electric Vehicle 2 will have upon arrival at the next stop.
  • button 656 is selectable to end navigation mode (e.g., to stop providing step- by-step or turn-by-turn instructions to reach the destination).
  • Fig.6O illustrates an embodiment in which the user has traveled along suggested route 620-4 and is approaching the suggested charging stop along suggested route 620-4.
  • device 500 determines that the user has traveled along suggested route 620-4 and is approaching the suggested charging stop (e.g., suggested stop 632-2 from Fig.6K, represented by representation 660) using one or more device location mechanisms or processes (e.g., using a GPS locator on device 500, etc.).
  • instructions 642 is updated to indicate that the suggested charging stop is 400 feet ahead and on the left side of the road.
  • instructions 644 is updated to provide additional information about the suggested charging stop (e.g., that the charging station is located on the first floor).
  • user interface 640 includes route 648 corresponding to the upcoming route.
  • user interface 640 includes route 658 corresponding to the route that was traversed. Between route 648 and route 658, there may be a representation (e.g., indicator 646) of the current location of the user’s vehicle.
  • user interface 640 includes representation 660 corresponding to the suggested stop (e.g., suggested stop 632-2 from Fig.6K).
  • representation 660 is displayed at a location on the representation of the map corresponding to the location of the suggested stop.
  • representation 660 is an icon of an electric vehicle charging station.
  • representation 660 includes a textual description of the suggested stop (e.g., the name of the suggested stop, the name of the charging station, the charging network associated with the charging station, etc.).
  • Fig.6P illustrates an embodiment in which the user has arrived at the suggested charging stop (or optionally within a threshold distance from the suggested charging stop, such as 50 feet, 100 feet, 300 feet, 500 feet, 1500 feet, etc.).
  • instructions 642 is updated to indicate that the user has arrived at the suggested stop.
  • instructions 644 is updated to suggest that the user use Adapter 1 to convert the plug used by Electric Vehicle 2 to a plug type that is compatible with the charging station.
  • determination that Adapter 1 is required to convert the plug type installed on Electric Vehicle 2 to a plug type that is compatible with the charging station is based on information received about Electric Vehicle 2 as described below with respect to method 900 (e.g., information about the compatible plug types, information about available adapters, etc.). It is understood that providing information regarding required adapters can be applied to vehicles of other fuel types (e.g., gasoline vehicles, electric vehicles, hybrid vehicles, plug-in hybrid vehicles, etc.).
  • Fig.6Q illustrates an embodiment in which device 500 has determined that Electric Vehicle 2 is being charged.
  • device 500 receives information about the charging status from a source external to the map application (e.g., an application other than the map application, or a server external to device 500) as described below with respect to method 900.
  • instructions 642 is updated to instruct the user to charge Electric Vehicle 2 to at least 53% and that the charging is estimated to take 15 minutes.
  • the estimated remaining charge time is determined based on information received from the source external to the map application.
  • user interface 640 in response to determining that Electric Vehicle 2 is being charged, user interface 640 is updated to display route 648 corresponding to the forward route to reach the destination.
  • user interface 650 is updated to include button 662.
  • button 662 is selectable to pause navigation mode (e.g., while the vehicle is charging).
  • pausing navigation mode returns the map application to a browsing mode in which a user is able to interact with the representation of the map and search for locations (and optionally provides for easy resumption of navigation mode, as described below), such as shown in Fig.6A.
  • a user input 603q is received selecting button 662.
  • device 500 pauses (e.g., ceases, ends, or stops) navigation mode (and optionally displays user interface 600, such as in Fig.6A).
  • Fig.6R illustrates an exemplary lock or wake screen user interface 664 while Electric Vehicle 2 is being charged (e.g., optionally after the user has paused navigation mode via selection of button 662, after the user has locked device 500 or placed device 500 in a low power mode, or after navigating away from a user interface of the map application, such as user interface 600).
  • a lock or wake screen user interface (e.g., such as user interface 664) is a user interface that is initially displayed upon waking device 500 after waking device 500 from a low power mode.
  • notification 668 that includes the charging status of the vehicle and/or the remaining charging time.
  • notification 668 indicates that there is five minutes of estimated time remaining to reach the suggested charge level.
  • the suggested charge level is selected based on the remaining distance to the destination (e.g., the amount of charge required to reach the destination, the amount of charge required to reach the destination with a threshold amount of remaining charge and/or remaining driving range).
  • notification 668 is periodically updated (e.g., every 10 seconds, 30 seconds, 1 minute, 5 minutes, 10 minutes, etc.) to indicate the estimated remaining time to charge the vehicle to the suggested charge level.
  • notification 668 indicates the current charge level (or gasoline level for a gasoline vehicle, or any other relevant fuel amount for vehicles of other fuel types).
  • notification 668 is displayed on any user interface and is not limited to only a lock or wake screen user interface.
  • notification 668 can be displayed while device 500 is displaying a system user interface (e.g., the home screen user interface, an application launching user interface, a settings user interface) or a user interface of an application.
  • notification 668 can be displayed on a notification user interface (e.g., a user interface that includes one or more active notifications).
  • notification 668 is persistent and remains displayed on the lock or wake screen user interface (optionally and on the notification user interface) while Electric Vehicle 2 is being charged.
  • notification 668 is automatically dismissed (e.g., removed from lock or wake screen user interface 664 and/or the notification user interface) in accordance with a determination that Electric Vehicle 2 has stopped charging.
  • notification 668 can be manually dismissed in response to a user input requesting dismissal of notification 668.
  • Fig.6S illustrates notification 668 when device 500 determines that Electric Vehicle 2 has reached the suggested charge level.
  • notification 668 indicates that Electric Vehicle 2 is ready to continue travelling towards the destination. In some embodiments, notification 668 indicates that Electric Vehicle 2 has reached the suggested charge level. In some embodiments, notification 668 indicates the current charge level. [0196] In some embodiments, selection of notification 668 (e.g., while Electric Vehicle 2 is charging or after Electric Vehicle 2 has completed charging) initiates a process to display the map application (e.g., user interface 600) and/or to resume navigation (e.g., optionally after device 500 has been unlocked). In some embodiments, if Electric Vehicle 2 has charged beyond the suggested level, then notification 668 can indicate that Electric Vehicle 2 has charged beyond the level required and that Electric Vehicle 2 is ready to continue along the suggested route.
  • the map application e.g., user interface 600
  • resume navigation e.g., optionally after device 500 has been unlocked
  • Fig.6T illustrates an exemplary user interface 600 of the map application while Electric Vehicle 2 is being charged, such as in response to a user selection of button 662.
  • user interface 606 includes an indication 672 to charge Electric Vehicle 2 for another 15 minutes.
  • indication 672 is periodically updated (e.g., every 10 seconds, 30 seconds, 1 minute, 5 minutes, 10 minutes, etc.) to indicate the estimated remaining time to charge the vehicle to the suggested charge level.
  • indication 672 indicates the current charge level.
  • indication 672 indicates the current fuel level (e.g., gasoline level for gasoline vehicles, etc.).
  • Fig.6U illustrates indication 672 when device 500 determines that Electric Vehicle 2 has reached the suggested charge level.
  • indication 672 indicates that Electric Vehicle 2 is ready to continue travelling towards the destination.
  • indication 672 indicates that Electric Vehicle 2 has reached the suggested charge level.
  • indication 672 is selectable to resume navigation mode (e.g., and optionally display user interface 640).
  • a user input 603u is received selecting indication 672.
  • device 500 resumes navigation mode of suggested route 620-4 and displays user interface 640, as shown in Fig.6V.
  • navigation mode of suggested route 620-4 is optionally resumed in response to selection of notification 668 shown in Fig.6S.
  • selection of notification 668 or indication 672 before the vehicle has reached the suggested charge level does not cause resumption of navigation mode.
  • selection of notification 668 or indication 672 before the vehicle has reached the suggested charge level does cause resumption of navigation mode (but optionally could cause the addition of another suggested stop, such as described below with respect to Fig.6V).
  • Fig.6V illustrates an embodiment in which device 500 determines that a (or another) refueling and/or recharging stop is required to reach the destination while in navigation mode.
  • a refueling and/or recharging stop was not previously recommended but based on updated information, a refueling and/or recharging stop is now recommended. For example, based on updated information, device 500 determines that Electric Vehicle 2 will not reach the destination (or optionally will reach the destination with less than a threshold amount of charge or less than a threshold amount of driving range remaining).
  • the updated information is an updated estimated driving range of Electric Vehicle 2 and/or an updated charge level of Electric Vehicle 2, such as described below with respect to method 900. For example, in Fig.6V, device 500 determines that Electric Vehicle 2 only has 10% charge remaining and may not reach the destination.
  • a suggested stop is required if the original estimated driving range was not accurate, because the driving economy of the vehicle changed (e.g., due to aggressive or influenced driving), because Electric Vehicle 2 did not follow the suggested route, or any other potential reason.
  • device 500 determines (or the above-described navigation server determines) the appropriate suggested stop and determines whether the route should be modified. For example, in Fig.6V, user interface 640 is updated to display route 648 that includes a suggested stop 684. As shown in Fig.6V, route 648 is a modified route to the same destination that includes the suggested stop.
  • route 648 is a suggested route.
  • route 682 is displayed corresponding to the original suggested route (e.g., without the suggested stop).
  • user interface 674 is displayed indicating that a suggested stop is recommended and requesting confirmation of whether to add the suggested stop to the navigation route.
  • user interface 674 includes textual indication 676 that indicates that a charging stop is required or suggested because there is not enough charge to reach the destination.
  • user interface 674 includes button 678 that is selectable to dismiss user interface 674, to decline adding the suggested stop, and to continue along the original route (e.g., along route 682).
  • user interface 674 includes button 680 that is selectable to confirm addition of the suggested stop and to navigate along route 648 (including stopping at the suggested stop).
  • device 500 can display suggested stops to recharge and/or refuel at a compatible station.
  • Figs.6W-6FF illustrate embodiments in which suggested routes are selected based on the characteristics of respective vehicles with respect to driving restrictions.
  • device 500 displays user interface 600 of the map application and user interface 606.
  • Fig. 6W illustrates in which suggested routes are selected based on the characteristics of respective vehicles with respect to driving restrictions.
  • user interface 600 does not include any suggested routes or driving directions and is optionally a default user interface of the map application (e.g., in a browsing state) that includes location indicator 602.
  • user interface 606 includes search field 670.
  • user interface 606 includes indication 686.
  • indication 686 is displayed in accordance with a determination that the current location of device 500 is within or near a geographic region in which a driving restriction exists. [0203] In the embodiments illustrated in Figs.6W-6FF, the respective driving restriction is based on the license plate of the vehicle, but it is understood that any driving restriction is possible.
  • a driving restriction corresponds to a restriction that defines that a certain set of vehicles may travel without restriction and a second set of vehicles are restricted from travel.
  • other restrictions are possible (e.g., a first set of vehicles must follow a certain set of rules or regulations while a second set follows a different set of rules or regulations, or all vehicles with a certain characteristic(s) are restricted from travel, etc.). For example, if a particular region or set of roads are controlled by a driving restriction, certain vehicles with certain characteristics defined by the restriction may be restricted from traveling within the region (or on the roads), while other vehicles without those certain characteristics may not be restricted from traveling within the region (or on the roads).
  • a restriction can exist in which odd numbered license plates (e.g., vehicles with license plates that end in an odd number) are prohibited from driving in a particular location during particular times and dates while even numbered license plates (e.g., vehicles with license plates that end in an even number) are not prohibited from driving at any time (or are prohibited from driving in the particular location during other times).
  • Another example of a driving restriction can be that vehicles over a particular gross weight are prohibited from driving on a particular highway during business hours, while vehicles under the gross weight threshold are not prohibited from driving on the highway.
  • indication 686 includes affordance 688 that is selectable to provide one or more vehicle license plates to the map application.
  • indication 686 is displayed only if no license plates have yet been provided to the map application. Thus, in some embodiments, indication 686 is not displayed after the user adds a first license plate to the map application (optionally even if the current location of device 500 is within or near a geographic region in which a driving restriction exists). In some embodiments, indication 686 can be displayed even if the user has added a license plate to the map application if the current location of device 500 is within or near a geographic region in which a driving restriction that is not based on a vehicle’s license plate exists and suggest to the user to provide other characteristic information for their vehicle (e.g., based on height, width, number of axles, weight, or any other suitable characteristic of the vehicle, etc.).
  • Fig.6X illustrates an embodiment in which suggested routes are provided to the user with respect to a driving restriction.
  • user interface 600 includes an indication 698 of the region that is subject to the driving restriction.
  • indication 698 is a visual element that visually differentiates the geographic region that is subject to the driving restriction from the areas that are not subject to a driving restriction (e.g., with a grey color, with a fill pattern, etc.).
  • user interface 600 includes suggested route 620-6 and suggested route 620-7.
  • suggested route 620-6 travels through the geographic region that is subject to the driving restriction.
  • suggested route 620-6 includes indicator 692 on the border of the geographic region that is subject to the driving restriction to indicate that the user may become subject to the driving restriction at the location indicated by indicator 692.
  • label 690-1 corresponding to suggested route 620-6 indicates that suggested route 620-6 is the fastest route (and is estimated to take 30 minutes) and includes an icon that indicates that a driving restriction may apply to the user’s vehicle.
  • suggested route 620-7 travels around the geographic region that is subject to the driving restriction and does not include an indicator that indicates that the user may become subject to the driving restriction.
  • label 690-2 corresponding to suggested route 620-7 indicates that suggested route 620-7 avoids the driving restriction. As shown in Fig.6X, no vehicle is currently selected, so device 500 does not have license plate information for the vehicle that the user intends to use to travel along the suggested routes.
  • device 500 provides at least one route that is selected without regard to the driving restriction (e.g., the fastest route, such as suggested route 620-6) and at least one route that is selected to avoid the driving restriction (e.g., the fastest route that avoids the driving restriction, such as suggested route 620-7).
  • only one suggested route is displays (e.g., only the fastest route without regard to the restriction or only the fastest route that avoids the restriction).
  • user interface 606 includes listing 616-1 corresponding to suggested route 620-6 and listing 616-2 corresponding to suggested route 620-7.
  • listing 616-1 includes indication 630-1 that indicates that suggested route 620-6 is subject to driving restrictions.
  • indication 630-1 includes link 694 that is selectable to display details about the respective driving restriction that applies in the respective geographic region.
  • listing 616-2 does not include an indication that suggested route 620-7 is subject to driving restrictions, but includes an indication that suggested route 620-7 avoids the driving restriction to which suggested route 620-6 is subject.
  • map user interface 600 does not include indication 698 of the region that is subject to the driving restriction.
  • Fig.6B no driving restrictions apply in the region displayed by the representation of the map, and thus device 500 does not display an indication of a driving restriction (e.g., does not include indication 698, indication 630-1 and/or link 694).
  • Fig.6Y user input 603y is received selecting link 694 corresponding to a request to display more information about the driving restriction.
  • device 500 in response to user input 603y, updates user interface 607 to display information about the driving restriction, as shown in Fig.6Z.
  • updated user interface 607 includes description 696 that describes the driving restriction that applies, optionally including description of what the restriction is and which vehicles are subject to the restrictions.
  • description 696 indicates that vehicles with license plate numbers that end in an odd number are prohibited from driving inside the restricted region (e.g., Downtown Pleasanton) on Tuesdays and Thursdays between 7:00 AM and 6:30 PM.
  • device 500 is able to determine whether a particular car is subject to the restriction and the times at which the car is subject to the restriction, and select suggested routes based on the determination.
  • an upward swipe 603aa of a contact on user interface 607 is detected (e.g., an upward swipe from a contact on user interface 607 illustrated in Fig.6Y), causing expansion of user interface 607 (e.g., similar to Fig.6C).
  • expanded user interface 607 includes vehicle list 622.
  • vehicle list 622 includes vehicle option 624-1, vehicle option 624-2, and no vehicle option 624-3.
  • vehicle option 624-1 corresponds to a first vehicle that has been registered with (e.g., added to) the map application (e.g., the user has provided license plate information for the first vehicle to the map application)
  • vehicle option 624-2 corresponds to a second vehicle that has been registered with the map application (e.g., the user has provided license plate information for the second vehicle to the map application).
  • vehicle 1 is a gas vehicle and vehicle 2 is an electric vehicle.
  • no vehicle option 624-3 corresponds to no specific vehicle and selection of vehicle option 624-3 causes the map application to suggest routes that are selected without consideration of the characteristics of a specific vehicle (e.g., without respect to whether a particular car is subject to a restriction), such as described above with respect to Fig.6Y.
  • a user input 603bb is received selecting vehicle option 624-2 corresponding to Electric Vehicle 2.
  • Electric Vehicle 2 in response to user input 603bb, Electric Vehicle 2 becomes the selected vehicle, as shown in Fig.6CC.
  • Fig.6CC because suggested routes were displayed when the user selected Electric Vehicle 2, the suggested routes are updated to be customized for Electric Vehicle 2.
  • a customized route for a vehicle is selected based on the license plate information of Electric Vehicle 2 (e.g., additionally or alternatively to vehicle characteristics described with reference to Figs.6A-6V).
  • device 500 is able to determine, based on the provided license plate information of Electric Vehicle 2, whether Electric Vehicle 2 is permitted to drive in the restricted region or prohibited from driving in the restricted region (e.g., based on the driving restriction rules, optionally at the current time or optionally at a future time selected by the user).
  • Electric Vehicle 2 has an odd license plate number (e.g., the last number of the license plate is an odd number), and thus would be prohibited from driving inside Downtown Desion on Tuesdays and Thursdays between 7:00 AM and 3:1 PM.
  • suggested route 620-7 is now the first suggested route (e.g., displayed first in user interface 607 and displayed on the map user interface with a prioritized visual characteristic).
  • one or more of the suggested routes travel through the restricted region even though Electric Vehicle 2 is prohibited from driving in the restricted region.
  • suggested route 620-6 is the fastest route, but because suggested route 620- 6 travels through the restricted region, suggested route 620-6 is not displayed first and is displayed in the map user interface with a de-prioritized visual characteristic.
  • a user input 603cc is received selecting button 618-1 corresponding to a request to begin navigation mode using suggested route 620-6, as shown in Fig.6CC.
  • the selected vehicle e.g., Electric Vehicle 2
  • device 500 in response to user input 603cc, begins navigation mode and displays user interface 640, as shown in Fig.6DD.
  • Fig.6DD illustrates an embodiment in which the user has traveled along suggested route 620-6 and is approaching the boundary of the restricted region (e.g., within 50 feet, 100 feet, 300 feet, 500 feet, 1000 feet, 3000 feet, etc.).
  • device 500 determines that the user has traveled along suggested route 620-6 and is approaching the boundary of the restricted region using one or more device location mechanisms or processes (e.g., using a GPS locator on device 500, etc.).
  • the restricted region is visually differentiated from the non-restricted region (e.g., similar to indication 698 in Fig.6X).
  • indication 646 is displayed at or near the boundary of the restricted region indicating the point at which the restricted region begins.
  • device 500 displays user interface 699 in response to the device 500 coming within a threshold distance (e.g., 100 feet, 300 feet, 500 feet, 1000 feet, 3000 feet, etc.) of the location of the restriction boundary, and user interface 699 optionally includes description 697 that provides a warning that the restricted region is ahead.
  • description 697 includes a brief description of the restriction (e.g., that odd numbered plates are affected).
  • device 500 provides indications and/or warnings that the user is about to enter a restricted region, device 500 does not prevent the user from entering the restricted region or limit the navigational or mapping functionalities of the device as the user enters the restricted region or while the user is in the restricted region.
  • Figs.6EE-6FF illustrate an embodiment in which suggested routes are selected for a vehicle that that is not prohibited from driving within a restricted region.
  • a user input 603ee is received selecting listing 624-1 from vehicle list 622 on expanded user interface 606.
  • Gas Vehicle 1 becomes the selected vehicle, as shown in Fig.6FF.
  • suggested routes were displayed when the user selected Gas Vehicle 1, the suggested routes are updated to be customized for Gas Vehicle 1.
  • a customized route for a vehicle is selected based on the license plate information of Gas Vehicle 1.
  • device 500 is able to determine, based on the provided license plate information of Gas Vehicle 1, whether Gas Vehicle 1 is permitted to drive in the restricted region or prohibited from driving in the restricted region (e.g., based on the driving restriction rules, optionally at the current time or optionally at a future time selected by the user).
  • Gas Vehicle 1 has an even license plate (e.g., the last number of the license plate is an even number) and thus is not prohibited from driving inside Downtown Pleasanton.
  • the suggested routes are selected without regard to the restriction of the restricted region.
  • suggested route 620-6 is the first suggested route (e.g., displayed first in user interface 606 and displayed on the map user interface with a prioritized visual characteristic), optionally because suggested route 620-6 is the fastest route.
  • suggested route 620-8 is an alternative route (e.g., alternative to suggested route 620-6). As shown in Fig.6FF, both suggested route 620-6 and suggested route 620-8 travel into and/or through the restricted region.
  • user interface 600 does not display any indication that the suggested routes are subject to the restricted region.
  • user interface 600 still includes indicator 698 that indicates the area of the restricted region.
  • one or more of the suggested routes for Gas Vehicle 1 are the same routes as shown in Fig.6X (e.g., suggested route 620-6 corresponding to the fastest route). In some embodiments, one or more routes of the suggested routes for Gas Vehicle 1 are different routes than those shown in Fig.6X (e.g., suggested route 620-8 is different from suggested route 620-7 because suggested route 620-7 is optionally selected to avoid the restriction whereas suggested route 620-8 is not required to avoid the restriction due to the restriction not applying to Gas Vehicle 1).
  • Fig.6FF does not illustrate the inclusion of the indications that the suggested routes may be subject to driving restrictions (e.g., such as in Fig.6 X and Fig.6CC)
  • user interface 600 includes the indications on the suggested routes and on the listings, even though Gas Vehicle 1 is not itself prohibited from driving in the restricted region (e.g., in the case that Gas Vehicle 1 is selected by mistake, the user is able to see that a restriction exists).
  • driving restrictions that are based on the license plate number of a respective vehicle, the disclosure herein is not so limited.
  • the features described above can be applied to driving restrictions based on other characteristics of vehicles, such as a vehicle’s VIN, a vehicle’s height, width, length, weight, etc.
  • a respective driving restriction prohibits vehicles with more than two axles from traveling within a certain region or along a certain road
  • device 500 can provide a process for the user to provide information about the number of axles on the user’s vehicles (e.g., in a process similar to the process to provide license plate information described above), and device 500 can use the provided information to suggest routes that that are customized for the user’s vehicle (e.g., based on whether the user’s vehicle is prohibited or not prohibited from driving along particular routes.
  • Fig.7 is a flow diagram illustrating a method 700 of displaying customized navigation routes in accordance with some embodiments of the disclosure.
  • the method 700 is optionally performed at an electronic device such as device 100, device 300, and device 500 as described above with reference to Figs.1A-1B, 2-3, 4A-4B and 5A-5H. Some operations in method 700 are, optionally combined and/or the order of some operations is, optionally, changed.
  • the method 700 displays customized navigation routes. The method reduces the cognitive burden on a user when interacting with a user interface of the device of the disclosure, thereby creating a more efficient human-machine interface.
  • an electronic device 500 in communication with a display generation component and one or more input devices (e.g., a mobile device (e.g., a tablet, a smartphone, a media player, or a wearable device), or a computer, optionally in communication with one or more of a mouse (e.g., external), trackpad (optionally integrated or external), touchpad (optionally integrated or external), remote control device (e.g., external), another mobile device (e.g., separate from the electronic device), a handheld device (e.g., external), and/or a controller (e.g., external), etc.) displays (702), via the display generation component, a map user interface, such as user interface 600 in Fig.6A (e.g., a user interface that displays a representation of a map of a given geographic location).
  • a map user interface such as user interface 600 in Fig.6A (e.g., a user interface that displays a representation of a map of a given geographic location).
  • the display generation component is a display integrated with the electronic device (optionally a touch screen display), external display such as a monitor, projector, television, or a hardware component (optionally integrated or external) for projecting a user interface or causing a user interface to be visible to one or more users, etc.
  • the user interface is a user interface of a map application.
  • the map user interface is interactable by the user to view different geographic locations or change the zoom level of the map.
  • the electronic device while displaying the map user interface, receives (704), via the one or more input devices, a user input corresponding to a request to display directions from a first location to a second location via a given mode of transportation, such as user input 603a in Fig.6A (e.g., a request to determine one or more routes and/or directions from a first geographic location to a second geographic location).
  • a user selects the first and/or second geographic location.
  • the first or second geographic location is the determined current location of the electronic device.
  • the map user interface displays the one or more determined routes from the first geographic location to the second geographic location.
  • the one or more routes are displayed in the map user interface.
  • the user selects the mode of transportation for which to determine the route.
  • the electronic device is able to determine driving routes, public transportation routes, mass transit routes, walking routes, and/or bicycling routes, etc.
  • the device uses different processes, algorithms, and/or restraints when determining potential routes.
  • the electronic device in response to the user input (706), in accordance with a determination that a first vehicle is a currently selected vehicle for which to display directions in the map user interface (e.g., a first vehicle is selected from one or more vehicles that are registered and/or added to the electronic device), the electronic device displays (708), in the map user interface, a first suggested route from the first location to the second location based on a first characteristic of the first vehicle, such as suggested route 620-2 and/or suggested route 620- 3 based on the fuel level of Gas Vehicle 1 in Fig.6E (e.g., displaying a first proposed or suggested route from the first location to the second location).
  • a first vehicle is a currently selected vehicle for which to display directions in the map user interface
  • the electronic device displays (708), in the map user interface, a first suggested route from the first location to the second location based on a first characteristic of the first vehicle, such as suggested route 620-2 and/or suggested route 620- 3 based on the fuel level of Gas Vehicle 1 in Fig
  • the first vehicle travels using the selected mode of transportation (e.g., driving on roadways).
  • the first vehicle is a gas vehicle, a hybrid vehicle, an electric vehicle, or any car of any fuel type (e.g., unleaded fuel, diesel, hydrogen, ethanol, self-propelled, electricity, solar energy, bio energy, etc.).
  • the first suggested route is determined based on the characteristics of the selected first vehicle.
  • the first characteristic is the type of fuel used by the vehicle (e.g., gasoline, diesel, electricity, etc.).
  • the first characteristic is the fuel economy of the vehicle (e.g., number of miles or kilometers a vehicle is able to travel per unit of fuel).
  • the first characteristic is the current effective range of the vehicle (e.g., number of miles or kilometers the vehicle is currently able to travel without refueling and/or recharging).
  • the first characteristic is the type of vehicle (e.g., passenger vehicle, commercial vehicle, truck, semi-trailer truck, etc.).
  • the first characteristic is the weight of the vehicle (e.g., vehicle with a certain current gross weight).
  • the first characteristic is the size of the vehicle (e.g., vehicle with a certain height clearance, vehicle with a certain width clearance, etc.).
  • the first characteristic is the power of the vehicle (e.g., horsepower, torque, etc.).
  • the first characteristic is an identifier of the vehicle (e.g., license plate number, vehicle identification number (VIN), serial number, etc.).
  • the first suggested route is determined based on the selected first vehicle’s ability to traverse the potential routes from the first location to the second location (e.g., based on the value of the first characteristic). For example, if the first vehicle is an electric vehicle with a range of 100 miles and all routes from the first location to the second location are over 100 miles, then the first suggested route includes a stop to charge the batteries (e.g., at an EV charging station) to allow the first vehicle to reach the second location.
  • the batteries e.g., at an EV charging station
  • the first suggested route does not include the stop to charge the batteries.
  • the first vehicle is a gas vehicle with a range of 250 miles and all routes from the first location to the second location are over 250 miles, then the first suggested route includes a stop to purchase gas (e.g., at a gas station) to fill the gas tank.
  • the first vehicle is a semi-trailer truck with a gross weight over a threshold amount, then the first suggested route automatically excludes roads and streets whose maximum weight restrictions are below the gross weight of the vehicle.
  • the first suggested route excludes routes that the vehicle would be unable to traverse. In some embodiments, if the first vehicle is a wide vehicle or tall vehicle, then the first suggested route excludes routes that require a narrow or low clearance. These and other characteristics that affect a vehicle’s ability to travel from one location to another are contemplated. In some embodiments, information about the first characteristic of the first vehicle is received from a source external to the map application, as described below with respect to method 900.
  • the electronic device displays (710), in the map user interface, a second suggested route from the first location to the second location, different from the first suggested route, based on a second characteristic of the second vehicle, such as suggested route 620-4 and suggested route 620-5 based on the current charge level of Electric Vehicle 2 in Fig.6K (e.g., displaying a second proposed or suggested route from the first location to the second location for the same mode of transportation (e.g., driving on roadways) as would be used for the suggested route for the first vehicle).
  • a second characteristic of the second vehicle such as suggested route 620-4 and suggested route 620-5 based on the current charge level of Electric Vehicle 2 in Fig.6K
  • the second vehicle is a gas vehicle, a hybrid vehicle, an electric vehicle, or any car of any fuel type (e.g., unleaded fuel, diesel, hydrogen, ethanol, self- propelled, electricity, solar energy, bio energy, etc.).
  • the second suggested route is determined based on the characteristics of the selected second vehicle.
  • one or more characteristics of the second vehicle is different from one or more characteristics of the first vehicle, which results in the second suggested route being different from the first suggested route.
  • the second suggested route takes a different route than the first suggested route.
  • the second suggested route includes more or fewer stops than the first suggested route.
  • the second characteristic of the second vehicle is the same characteristic type as the first vehicle, but has a different value than the first vehicle.
  • the first and second vehicle are optionally both gas vehicles (e.g., same fuel type), but have different effective ranges (e.g., the first vehicle has enough gas to travel 100 miles while the second vehicle has enough gas to travel 50 miles).
  • the suggested route for the first vehicle is different from the suggested route for the second vehicle based on the distance between the first and second location and whether stops are required to purchase gas.
  • the second characteristic of the second vehicle is a different characteristic type than the first characteristic of the first vehicle.
  • the first vehicle is optionally a gas vehicle and the second vehicle is optionally an electric vehicle (e.g., different fuel types), and the first suggested route doesn’t take into account the effective range of the first vehicle while the second suggested route does take into account the effective range of the second vehicle.
  • the suggested route for the second vehicle is optionally different from the suggested route for the first vehicle if a stop is required to charge the second vehicle in order to reach the destination.
  • certain license plate patterns are restricted in a certain geography and the device is able to suggest routes based on the applicable restrictions. For example, some geographies may restrict travel based on whether a vehicle’s license plate is even or odd.
  • the electronic device optionally suggests a first route for the first vehicle based on whether odd numbered license plates are currently restricted and optionally suggests a second, different, route for the second vehicle based on whether even numbered license plates are currently restricted.
  • information about the second characteristic of the second vehicle is received from a source external to the map application, as described below with respect to method 900.
  • the first characteristic of the first vehicle includes a first current estimated driving range for the first vehicle, such as in Fig.6E (e.g., the first characteristic is an estimate of the distance that the first vehicle is able to drive on the current fuel or charge level).
  • the estimate of the distance that the first vehicle is able to drive depends on the current fuel or electric charge level, the driving efficiency of the vehicle, the recent driving patterns of the first vehicle, and/or the habits of the driver, etc.
  • the first suggested route is based on the first current estimated driving range, such as in Fig.6E (e.g., the first suggested route is selected based on the estimate of the distance that the first vehicle is able to drive on the current fuel or charge level).
  • the first suggested route includes a suggested stop to refuel or recharge the vehicle (e.g., at a gas station or electric vehicle charging station) if the first current estimated driving range is not enough for the first vehicle to reach the second location from the first location.
  • the first suggested route includes a suggested stop to refuel or recharge the vehicle if the estimated fuel level or battery charge level when the vehicle reaches the destination is less than a threshold amount (e.g., such as less than 5%, 10%, 15%, 20%, etc. of fuel or charge remaining, or with less than 2 miles, 5 miles, 10 miles, 20 miles, 50 miles, etc. of driving range remaining).
  • a threshold amount e.g., such as less than 5%, 10%, 15%, 20%, etc. of fuel or charge remaining, or with less than 2 miles, 5 miles, 10 miles, 20 miles, 50 miles, etc. of driving range remaining.
  • the first suggested route is selected to be less than the estimate of the distance that the first vehicle is able to drive (e.g., even if it is a slower route). In some embodiments, the first suggested route is selected to increase the driving economy of the first vehicle (e.g., selecting routes with more steady driving, etc.) if the estimated driving range is close to the distance from the first location to the second location, for example.
  • the second characteristic of the second vehicle includes a second current estimated driving range for the second vehicle, different from the first current estimated driving range, such as in Fig.6K (e.g., the current estimated driving range for the second vehicle is different from the current estimated driving range for the first vehicle).
  • the current estimate driving range for the second vehicle is different from the first vehicle because the vehicles have a different amount of fuel or charge and/or the vehicles have different driving efficiencies (e.g., fuel or charge efficiency).
  • the second suggested route is based on the second current estimated driving range, such as in Fig.6K (e.g., the second suggested route is selected based on the estimate of the distance that the second vehicle is able to drive on the current fuel or charge level).
  • the second suggested route includes a suggested stop to refuel or recharge the vehicle (e.g., at a gas station or electric vehicle charging station) if the second current estimated driving range is not enough for the second vehicle to reach the second location from the first location.
  • the second suggested route is the same route as the first suggested route (e.g., same route optionally with the same suggested stops). In some embodiments, the second suggested route is a different route than the first suggested route (e.g., different route optionally with different suggested stops or no suggested stops).
  • the above-described manner of displaying different routes based on the estimated driving range of different vehicles for which directions are requested quickly and efficiently provides appropriate routes to travel from a first to a second location (e.g., by automatically taking into consideration the driving range of the vehicle in suggesting routes), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., without requiring the user to separately determine whether the user’s vehicle is able to reach the destination without running out of fuel or charge), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the first suggested route includes a suggested stop for increasing a remaining driving range of the first vehicle, such as suggested stop 632-1 in Fig.
  • the first suggested route includes a suggested stop to refuel or recharge the first vehicle (e.g., at a gas station or electric vehicle charging station).
  • the first suggested route includes a plurality of suggested stops to refuel or recharge the first vehicle if multiple stops to refuel or recharge are required to reach the second location from the first location.
  • the second suggested route includes a suggested stop to refuel or recharge the second vehicle if the second current estimated driving range for the second vehicle is less than the distance to drive from the first location to the second location.
  • the suggested stop for the second vehicle is different from the suggested stop for the first vehicle based on the difference in the characteristics of the two vehicles (e.g., different fuel types, different driving range, etc.). In some embodiments, the second suggested route for the second vehicle does not include a suggested stop.
  • the above-described manner of including a suggested stop in the suggested routes quickly and efficiently provides appropriate routes to travel from a first to a second location (e.g., by automatically taking into consideration whether the vehicle should be refueled or recharged along the way in order to reach the destination), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., without requiring the user to separately determine whether the user’s vehicle is able to reach the destination and then manually searching for and adding a refueling or recharging stop to the route), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the suggested stop for increasing the remaining driving range of the first vehicle is a first stop associated with the first charging network, such as in Fig.6L (e.g., the suggested stop is within the network of charging stations, is a charging station of the charging station company, or is a gas station of the gas station company that the user has a relationship with or prefers).
  • the first vehicle’s association with a particular charging network is set by a user or provided by a third-party application or server as described below with respect to method 900.
  • device 500 is able to determine the charging stations and/or gas stations within the user’s network (e.g., network that the user or vehicle is associated with, a preferred network, or required network for the first network) and suggest those particular stations.
  • determining the charging station and/or gas station within the user’s network includes receiving information for the charging network and/or gas station from a source external to the map application, as discussed below with respect to method 900.
  • the suggested stop in accordance with a determination that the first vehicle is associated with a second charging network, different from the first charging network, the suggested stop is a second stop, different from the first stop, associated with the second charging network.
  • the above-described manner of displaying suggested stops that are within a particular charging network quickly and efficiently provides appropriate recharging stops along the route from a first to a second location (e.g., by automatically taking into consideration the charging network that is preferred by the user or otherwise associated with the vehicle when determining the recharging stops to add to the suggested route), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., without requiring the user to separately determine whether the suggested recharging stop is within the user’s charging network), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the first characteristic of the first vehicle includes a first current estimated driving range for the first vehicle, such as in Fig.6E (e.g., the first characteristic is an estimate of the distance that the first vehicle is able to drive on the current fuel or charge level).
  • the estimate of the distance that the first vehicle is able to drive depends on the current fuel or electric charge level, the driving efficiency of the vehicle, the recent driving patterns of the first vehicle, and/or the habits of the driver, etc.
  • the first suggested route is based on the first current estimated driving range, such as in Fig.6E (e.g., the first suggested route is selected based on the estimate of the distance that the first vehicle is able to drive on the current fuel or charge level).
  • the first suggested route includes a suggested stop to refuel or recharge the vehicle (e.g., at a gas station or electric vehicle charging station) if the first current estimated driving range is not enough for the first vehicle to reach the second location from the first location.
  • the electronic device in response to the user input, in accordance with a determination that a third vehicle (e.g., a no vehicle option) is currently selected for which to display directions in the map user interface, displays, in the map user interface, a third suggested route from the first location to the second location, that is not based on a current estimated driving range for a vehicle, such as suggested route 620-1 and suggested route 620-2 in Fig.6B when no vehicle is selected (e.g., no vehicle has been selected for which to provide customized routes).
  • the map application includes a list of vehicles that have been registered with the map application from which the user is able to select a car to determine directions from.
  • the list of vehicles includes an “other vehicle” option (or optionally an option to disable customized routes) that is not associated with a particular, the selection of which causes the device to provide generic routes (e.g., not customized to a particular vehicle, and without regard to the characteristics of a particular vehicle).
  • “other vehicle” option to disable customized routes that are based on the characteristics of a particular vehicle or if the user otherwise disabled customized routes (e.g., via a setting), then customized estimated driving ranges are not available.
  • the third suggested route is selected without regard to the driving range of a particular vehicle (e.g., without regard to the current estimated driving range of the first vehicle or the current estimated driving range of the second vehicle).
  • the third suggested route does not automatically include any refueling or recharging stops.
  • the third suggested route is the fastest route from the first location to the second location.
  • the third suggested route is the shortest route from the first location to the second location.
  • the third suggested route is the same as the first suggested route and/or the second suggested route (e.g., if the first current estimated driving range is more than enough to reach the second location from the first location). In some embodiments, the third suggested route is different than the first suggested route and/or the second suggested route (e.g., if the first current estimated driving range is not enough to reach the second location from the first location).
  • the second suggested route is selected without regard to the driving range for the second vehicle (e.g., similar to the third suggested route described herein for generic vehicles), optionally with an indication that the suggested route is not customized for the second vehicle.
  • displaying the first suggested route from the first location to the second location includes displaying an estimated total travel time for the first suggested route, such as the indication of 59 minutes and 1 hour 4 minutes in Fig.6E (e.g., the first suggested route is displayed with an indication of an estimated amount of time to travel along the first suggested route to reach the second location from the first location).
  • the estimated total travel time includes an estimated time to increase the remaining driving range of the first vehicle at the suggested stop, such as in Fig.6E (e.g., if the first suggested route includes a suggested stop to refuel or recharge the vehicle, then the displayed estimated amount of time to travel includes an estimated amount of time required to refuel or recharge the vehicle). For example, if the amount of time it takes to recharge the vehicle to a respective suggested amount is estimated to take 15 minutes, then the estimated total travel time includes the 15 minutes of charge time.
  • the estimated total travel time includes the estimated time for refueling or recharging.
  • the above-described manner of displaying estimated travel time that includes time to refuel and/or recharge provides a more accurate estimate of the amount of time required to reach the destination (e.g., by automatically taking into consideration the amount of time required to refuel or recharge the vehicle at a suggested refueling or recharging stop), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., without requiring the user to separately determine how long the refueling or recharging will take and adding that to the estimated duration or estimated time of arrival), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the electronic device displays, via the display generation component, one or more representations of one or more segments associated with the first suggested route, such as in Fig.6F (e.g., while displaying the step-by-step directions of the first suggested route on a user interface (e.g., optionally in response to a user input selecting the first suggested route or a user input requesting display of the step-by-step directions of the first suggested route)), wherein a respective representation of a respective segment includes an indication of an estimated state of the first characteristic of the first vehicle during the respective segment, such as indication 638-1, indication 638-2, and indication 638-3 in Fig.6F (e.g., some or all of the step-by-step directions of the first suggested route are displayed with an indication of the estimated amount of fuel or charge level of the respective vehicle when the respective vehicles reaches the respective step-by-step direction or while the vehicle is following the respective step-by-step direction).
  • a respective representation of a respective segment includes an indication of an estimated state of the first characteristic of the first vehicle
  • the estimated fuel or charge level are displayed for steps that the first vehicle has not already followed (e.g., for future steps). In some embodiments, estimated fuel or charge level are not displayed for steps that the first vehicle has already performed. In some embodiments, the actual fuel or charge level are displayed for steps that the first vehicle has already performed.
  • the “start” step e.g., first step
  • the “arrive” step e.g., final step
  • the “start” step include an indication of the estimated charge level for when the vehicle begins traveling along the suggested route and the estimated charge level for when the vehicle arrives at the destination, respectively.
  • the suggested stop includes an indication of the estimated fuel or charge level for when the vehicle arrives at the suggested stop.
  • the estimated fuel or charge level can be displayed for other steps.
  • the estimated fuel or charge level is the estimated fuel or charge level for when the user arrives at the beginning of the step, when the user completes the step, or any time while the first vehicle is following the step (e.g., along the route corresponding to the step).
  • the estimated charge or fuel level updates while the first vehicle is traveling along the suggested route based on new or updated information for the current charge or fuel levels of the first vehicle.
  • the above-described manner of displaying estimates of the fuel or charge level at respective steps of the suggested route provides the user with information about the fuel or charge level, which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., allowing a user to determine, using the provided estimates, whether to select the suggested route, select another route, or modify the suggested route), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the electronic device receives, via the one or more input devices, a user input corresponding to a request to select the second vehicle as the currently selected vehicle, such as in Fig.6I (e.g., while displaying the suggested route(s) for the first vehicle, receive an input switching to the second vehicle).
  • a user input corresponding to a request to select the second vehicle as the currently selected vehicle, such as in Fig.6I (e.g., while displaying the suggested route(s) for the first vehicle, receive an input switching to the second vehicle).
  • other suggested routes are optionally also displayed.
  • the first suggested route is the recommended route and the other suggested routes are alternative routes and are optionally displayed de-emphasized as compared to the first suggested route (e.g., a dimmer color, a different color, with an indication that it is not the most recommended route, that it is an alternative route, etc.).
  • the second suggested route e.g., that would be displayed for the second vehicle were it selected is one of the other suggested routes that are displayed.
  • the electronic device in response to receiving the user input corresponding to the request to select the second vehicle as the currently selected vehicle, displays, in the map user interface, the second suggested route, such as in Fig.6J (e.g., switching from displaying the first suggested route to displaying the second suggested route).
  • the second suggested route is displayed because the second suggested route is the recommended route for the second vehicle based on the characteristic of the second vehicle.
  • the first suggested route is ceased to be displayed.
  • the first suggested route remains displayed but is displayed with an indication that it is not the most recommended route (e.g., displayed with a text that indicates that the first suggested route is an alternative route, or displayed with a de-emphasized color as compared to the second suggested route and/or as compared to the color of the first suggested route before receiving the input, etc.).
  • the second suggested route when the input was received, the second suggested route was displayed concurrently with the first suggested route, but was displayed with an indication that it was not the most recommended route, and in response to the user input, the second suggested route is updated to indicate that the second suggested route is now the most recommended route (e.g., not displayed with a text that indicates that the second suggested route is an alternative route, not displayed with a de-emphasized color, displayed with a text that indicates that it is the fastest route, displayed with an emphasized color, etc.).
  • the electronic device determines that the device has arrived at a suggested stop for increasing a remaining driving range of the first vehicle, such as in Fig.6P (e.g., the device and/or the first vehicle has reached the location of the suggested stop and/or has reached within a threshold distance of the location of the suggested stop (e.g., within 30 feet, 50 feet, 200 feet, 500 feet, 2000 feet, etc.)).
  • the first vehicle is an electric vehicle and the suggested stop is a charging station for charging the electric vehicle.
  • the electronic device in response to determining that the device has arrived at the suggested stop for increasing the remaining driving range of the first vehicle, in accordance with a determination that an accessory of a first type is required to increase the remaining driving range of the first vehicle, displays, via the display generation component, an indication of the accessory of the first type, such as instruction 644 in Fig.6P (e.g., displaying an indication of the type of adapter required to charge the first vehicle at the charging station associated with the suggested stop).
  • the charging station at the suggested stop is configured with one or more different outlet or plug types that are compatible with one or more charger plugs.
  • an accessory of a second type e.g., a second type of adapter
  • an indication of the accessory of the second type is displayed.
  • the first vehicle is equipped with a compatible charger plug
  • the first vehicle is able to use the charging station without using an adapter and thus an indication of an adapter is not displayed.
  • an indication of the adapter is displayed, thus indicating the adapter required to use the charging station.
  • the device provides only adapters that the user has previously indicated that the user is in possession of.
  • the above-described manner of displaying an accessory required to use the charging station quickly and efficiently provides the user with information of how to connect to the charging station (e.g., by automatically taking into consideration the requirements of the charging station, the type of plug installed on the vehicle, and the adapters that are available), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., without requiring the user to separately determine whether an adapter is required or whether the user’s vehicle is actually able to use the charging station), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the electronic device determines that the device has arrived at a suggested stop for increasing a remaining driving range for the first vehicle, such as in Fig.6P (e.g., the device and/or the first vehicle has reached the location of the suggested stop and/or has reached within a threshold distance of the location of the suggested stop (e.g., within 30 feet, 50 feet, 200 feet, 500 feet, 2000 feet, etc.)).
  • a threshold distance of the location of the suggested stop e.g., within 30 feet, 50 feet, 200 feet, 500 feet, 2000 feet, etc.
  • the electronic device in response to determining that the device has arrived at the suggested stop for increasing the effective range of the first vehicle, displays, via the display generation component, a first affordance to pause the navigation along the first suggested route, such as button 662 in Fig.6Q (e.g., displaying a button to pause navigation mode).
  • a first affordance to pause the navigation along the first suggested route such as button 662 in Fig.6Q (e.g., displaying a button to pause navigation mode).
  • the electronic device receives, via the one or more input devices, a user input selecting the first affordance, such as in Fig.6Q (e.g., a tap input on the button).
  • the electronic device in response to receiving the user input selecting the first affordance, displays, via the display generation component, a second affordance to resume navigating along the first suggested route (e.g., displaying a button to resume navigation mode) and an indication of the first characteristic of the first vehicle while it is increasing, such as notification 668 in Fig.6R or indication 672 in Fig.6T (e.g., display the current charge level, the current estimated driving range, and/or the amount of time remaining to recharge the first vehicle in order to reach the suggested charge level).
  • the button to resume navigation mode replaces the button to pause navigation mode.
  • the button to pause navigation mode becomes the button to resume navigation mode.
  • a selectable option is displayed on the map user interface for resuming navigating along the first suggested while not displaying any directions or routes.
  • the device displays a notification that is selectable to display the maps application and optionally resume navigating along the first suggested route.
  • the indication dynamically updates as updated information about the first characteristic is received.
  • the maps application continuously (e.g., at a predetermined frequency, such as once every 0.25 seconds, 0.5 seconds, 1 second, 3 seconds, 5 seconds, etc.) polls a third party application or source (e.g., as described below with respect to method 900) to receive updated information for the first characteristic.
  • the above-described manner of monitoring the first characteristic as the first vehicle is refueling or recharging quickly and efficiently provides the user with updates on the status of the refueling or recharging (e.g., by automatically displaying updated fuel and charge information even if the user has paused active navigation), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., without requiring the user to navigate to a separate user interface to determine to view the current status of the fuel or charge level), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the electronic device determines that a current estimated driving range for the first vehicle is less than a remaining driving distance of the first suggested route from a current location to the second location, such as in Fig.6V (e.g., while in navigation mode and traveling along the first suggested route, receiving updated information about the first vehicle and determining based on the updated information that the first vehicle will not reach the destination from the first vehicle’s current location).
  • the received updated information is an updated estimated driving range or an updated current charge or fuel level.
  • the updated information is received from a source external to the map application, such as described below with respect to method 900.
  • the electronic device in response to determining that the current estimated driving range for the first vehicle is less than the remaining driving distance of the first suggested route from the current location to the second location, updates the first suggested route to include a suggested stop for increasing a remaining driving range of the first vehicle, such as in Fig.6V (e.g., if the updated estimated driving range suggests that the first vehicle does not have enough fuel or electric charge to reach the destination (or will reach the destination with less than a threshold amount of fuel or charge, such as less than 5%, 10%, 15%, 20%, etc. of fuel or charge remaining, or with less than 2 miles, 5 miles, 10 miles, 20 miles, 50 miles, etc.
  • a threshold amount of fuel or charge such as less than 5%, 10%, 15%, 20%, etc.
  • the device is able to dynamically add suggested stops to refuel or recharge while in navigation mode or while the vehicle is traveling towards the destination, without requiring the user to perform another query to route from the vehicle’s current position to the destination to determine where to refuel or recharge the vehicle.
  • the first characteristic of the first vehicle is associated with a first driving restriction for the first vehicle, such as in Fig.6CC (e.g., a geographic region (e.g., city, county, area, etc.) has implemented driving restrictions that apply certain sets of vehicles based on the characteristics of the respective vehicle).
  • driving restrictions may be implemented based on the license plate of the vehicles. For example, during certain periods of time, odd numbered vehicles (e.g., vehicles with license plates ending in an odd number) are not permitted to drive in the restricted region, but even numbered vehicles (e.g., vehicles with license plates ending in an even number) are permitted to drive in the restricted region.
  • restrictions based on other characters are possible, such as the type of vehicle (e.g., whether the vehicle is a passenger vehicle, commercial vehicle, truck, SUV, semi-tractor trailer truck, whether the vehicle is taller than a certain height, whether the vehicle is above a certain gross weight, etc.).
  • the first suggested route is based on the first driving restriction, such as in Fig.6CC (e.g., the route suggested is based on whether the first vehicle is subject to the driving restriction).
  • the driving restriction is that even numbered cars are not permitted to drive in a restricted region and the normally suggested route (e.g., the fastest route) would route the vehicle through the restricted region
  • a route that avoids the restriction e.g., routes around the restricted region
  • the normally suggested route is also concurrently displayed to the user, but displayed with an indication that it is affected by the restriction.
  • the suggested route is only affected during those time windows (e.g., if the current time is outside the time window in which the restriction applies, then the suggested route is selected without regard to the restriction.
  • the second characteristic of the second vehicle is associated with a second driving restriction for the second vehicle, different from the first driving restriction, such as in Fig.6FF (e.g., the second vehicle has a different characteristic from the first vehicle and thus is either also restricted from driving in the restricted region or is not restricted from driving in the restricted region).
  • the second suggested route is based on the second driving restriction, such as in Fig.6FF (the suggested route for the second vehicle is based on whether the second vehicle is affected by the driving restriction).
  • the driving restriction that applies to the second vehicle is the same driving restriction than the one that applies to the first vehicle and the device is able to determine whether the first vehicle or the second vehicle is prohibited from traveling a particular route due to that driving restriction.
  • the driving restrictions that applies to the second vehicle is a different driving restriction than the one that applies to the first vehicle and the device is able to determine whether the second vehicle is able to travel a particular route based on the driving restriction that affects the second vehicle.
  • the suggested route for the second vehicle is the same as the suggested route for the first vehicle because the second vehicle and the first vehicle are similarly affected by the driving restriction (e.g., are both even numbered cars).
  • the suggested route for the second vehicle is different from the suggested route for the first vehicle because the vehicles are affected differently by the restriction.
  • the suggested route is selected without regard to the restriction (e.g., is the fastest route, and/or shortest route, etc.).
  • the second vehicle is affected by the same restriction as the restriction that affects the first vehicle and also an additional restriction, different from the restriction that affects the first vehicle, and the suggested route is selected to avoid both restrictions.
  • whether a car is affected by a restriction is based on the characteristics of the vehicle, such as the license plate pattern or the vehicle type.
  • a different set of restrictions apply to different types of vehicles (e.g., a first set of restrictions apply to passenger vehicles and a second set of restrictions apply to commercial vehicles, etc.).
  • the maps application receives information about the characteristics of the vehicle from a source external to the map application, as described below with respect to method 900.
  • a user provides the map application with license plate information, similarly to the process to add a vehicle to the maps app as described below with respect to method 900.
  • the first driving restriction is determined using an anonymized characteristic corresponding to the first characteristic of the first vehicle (e.g., anonymize the characteristic of the vehicle when determining the suggested route for the vehicle).
  • a third party server or third party service is used to gather travel information or road conditions. For example, a server hosted by a government agency provides current traffic information, current outages, viable routes, and/or restriction information. In some embodiments, a server maintains driving restriction information and is able to be queried to determine whether a particular vehicle is prohibited from driving in a restricted zone.
  • the server is queried by providing the vehicle’s license plate information and the intended route and the server provides a determination on whether the vehicle is prohibited from driving along a part of or all of the intended route.
  • the driving restriction is based on a pattern of the license plate (e.g., whether it ends in an even or odd number) rather than the full license plate number, the device is able to anonymize the license plate to preserve the privacy of the user and thus prevent information about the user’s travel habits or history from being sent away from the device and/or to another entity.
  • the device provides, to the server, a randomly generated license plate number (that optionally follows the license plate pattern of the region), that ends with a randomly generated even or odd number (whichever is the case based on whether the first vehicle is an even or odd number) to simulate the license plate pattern of the first vehicle while not providing the actual license plate information of the first vehicle.
  • a randomly generated license plate number that optionally follows the license plate pattern of the region
  • a randomly generated even or odd number (whichever is the case based on whether the first vehicle is an even or odd number) to simulate the license plate pattern of the first vehicle while not providing the actual license plate information of the first vehicle.
  • the device uses an anonymized characteristic that is the same type of characteristic as the first characteristic (e.g., optionally the characteristic that is relevant to the respective driving restriction.
  • the above-described manner of determining suggested routes using an anonymized characteristic of the vehicle quickly and efficiently determines the appropriate routes for the respective vehicle while maintaining the privacy of the user (e.g., by automatically removing identifying information when determining the routes to suggest), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., by allowing the user to enter the vehicle’s true details and without requiring the user to provide incorrect identifying information, which may result in incorrect determination of whether the user’s vehicle is restricted, for example, if the restriction is changed), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the first characteristic of the first vehicle is associated with a first driving restriction for the first vehicle, such as in Fig.6CC (e.g., the first characteristic of the first vehicle is relevant to a driving restriction for a restricted region and the first vehicle is either prohibited or not prohibited from traveling in the restricted region).
  • the license plate pattern of the first vehicle matches the restriction pattern such that the first vehicle is restricted or not restricted.
  • the first suggested route is based on the first driving restriction, such as in Fig.6CC (e.g., the first suggested route provided to the user is selected for the first vehicle based on whether the first vehicle is prohibited or not prohibited from driving in the restricted region).
  • the first suggested route is a route that avoids the restriction (e.g., goes around the restricted region). In some embodiments, if the first vehicle is not prohibited, the first suggested route is selected without regard to the restriction (e.g., is the fastest route or shortest route, etc.).
  • the electronic device in response to the user input, in accordance with a determination that no vehicle is currently selected for which to display directions in the map user interface, displays, in the map user interface, a third suggested route from the first location to the second location, that is not based on a driving restriction, such as in Fig. 6X (e.g., no vehicle has been selected for which to provide customized routes).
  • the map application includes a list of vehicles that have been registered with the map application from which the user is able to select a car to determine directions from.
  • the list of vehicles includes an “other vehicle” option (or optionally an option to disable customized routes) that is not associated with a particular, the selection of which causes the device to provide generic routes (e.g., not customized to a particular vehicle, and without regard to the characteristics of a particular vehicle).
  • the “other vehicle” option to disable customized routes that are based on the characteristics of a particular vehicle or if the user otherwise disabled customized routes (e.g., via a setting), then customized estimated driving ranges are not available.
  • the third suggested route travels through the restricted region.
  • the third suggested route is the fastest route from the first location to the second location.
  • the third suggested route is the shortest route from the first location to the second location.
  • the third suggested route is the same as the first suggested route and/or the second suggested route (e.g., if the first vehicle is not prohibited from traveling in the restricted region).
  • the third suggested route is different than the first suggested route and/or the second suggested route (e.g., if the first vehicle and/or the second vehicle are prohibited from traveling in the restricted region).
  • driving restriction information is not available for the second vehicle (e.g., because the map application is unable to communicate with the external source that is providing the information)
  • the second suggested route is selected without regard to the driving restrictions that may apply to the second vehicle (e.g., similar to the third suggested route described herein for generic vehicles, optionally with an indication that the suggested route is not customized for the second vehicle).
  • the electronic device displays, via the display generation component, an indication that the third suggested route passes through the area restricted by a driving restriction, such as in Fig.6X (e.g., if no vehicle is selected, then the suggested route that is displayed is displayed without regard to whether a specific vehicle is affected by a restricted region).
  • a driving restriction such as in Fig.6X
  • the electronic device displays, via the display generation component, an indication that the third suggested route passes through the area restricted by a driving restriction, such as in Fig.6X (e.g., if no vehicle is selected, then the suggested route that is displayed is displayed without regard to whether a specific vehicle is affected by a restricted region).
  • the indication is a text indicator that a restriction applies.
  • the indication is an icon indicating that a restriction applies.
  • the icon is displayed at or near the position of the portion of the suggested route that enters into the restriction region.
  • the icon is displayed on a respective listing of a suggested route in the list of suggested routes (which are optionally displayed in response to a request for directions) to indicate that the suggested route is affected by a driving restriction.
  • the indication identifies the type of restriction and/or indicates how or why the indication applies to certain vehicles (e.g., the indication includes a textual description of the restriction and/or the icon represents the type of restriction).).
  • the above-described manner of displaying an indication if a route is affected by a driving restriction quickly and efficiently provides the user with an indication that the user’s vehicle may be subject to the driving restriction (e.g., by displaying the indication that a driving restriction applies when the user has not selected a specific vehicle to search routes for), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., without requiring the user to always select a specific vehicle or requiring the user to add vehicles to the application before requesting directions to receive information about driving restrictions), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • a driving restriction e.g., when the route is a generic route that is not customized for a particular vehicle
  • the driving restriction e.g., by displaying the indication that a driving restriction applies when the user has not selected a specific vehicle to search routes for
  • the electronic device displays, via the display generation component, an affordance for adding information about a respective vehicle to the map user interface, such as button 688 in Fig.6W (e.g., display a notification, an element on the user interface, and/or a link or button that is selectable to initiate a process to add vehicle information to the map application).
  • a driving restriction e.g., if a suggested route travels through a restricted region and is thus affected by a driving restriction
  • one or more criteria e.g., no cars have yet been added to the to the map application
  • the electronic device displays, via the display generation component, an affordance for adding information about a respective vehicle to the map user interface, such as button 688 in Fig.6W (e.g., display a notification, an element on the user interface, and/or a link or button that is selectable to initiate a process to add vehicle information to the map application).
  • a notification is displayed on a lock screen, a wake screen, or on the notification user interface indicating that license plate information can be added to the map application.
  • a banner or other user interface element is displayed in the map application indicating that license plate information can be added to the map application.
  • the electronic device receives, via the one or more input devices, a user input selecting the affordance (e.g., a tap input or any other selection input on the affordance).
  • the electronic device in response to receiving the user input, initiates a process to add the information about the respective vehicle to the map user interface (e.g., initiate a process for the user to add license plate information to the maps application (e.g., information associated with the driving restriction)).
  • the process includes displaying a wizard or step-by-step instructions to guide the user through adding license plate information.
  • the maps application maintains a list of vehicles associated with the user, which optionally includes license plate information and/or other characteristics for the respective vehicles. In some embodiments, the characteristics of the vehicles are automatically populated with information received from an external source, as discussed below with respect to method 900.
  • the above-described manner of adding vehicle information (e.g., providing an affordance that is selectable to initiate a process to add vehicle information to the map application) quickly and efficiently provides the user with the ability to provide the map application with vehicle information that is relevant to a driving restriction, which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient, which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • vehicle information e.g., providing an affordance that is selectable to initiate a process to add vehicle information to the map application
  • the electronic device determines that a current location of the device satisfies one or more criteria associated with a driving restriction of the first suggested route, such as in Fig.6DD (e.g., while in navigation mode and traveling along the suggested route, determining that the user is about to enter into a restricted region (optionally only if the currently selected vehicle is prohibited from traveling in the restricted region or if no vehicle is currently selected)).
  • the suggested route includes directions that guides the user into a restricted region.
  • the suggested route that the user is traveling along is provided because the user has not selected a particular car to provide routes for or because the user chose to navigate using a route that travels into the restricted region.
  • the electronic device in response to determining that the current direction satisfies the one or more criteria associated with the driving restriction, displays, via the display generation component, an indication of the driving restriction, such as in Fig.6DD (e.g., within a threshold distance of entering into the restricted region (e.g., 10 feet, 50 feet, 100 feet, 300 feet, 500 feet, 1000 feet, etc.), displaying an indication that the user is about to enter the restricted region).
  • the indication is a textual indication that a restricted region is upcoming.
  • the indication is an icon in the user interface at or near the location corresponding to the restricted region.
  • the indication identifies the type of restriction and/or indicates how or why the indication applies to certain vehicles (e.g., the indication includes a textual description of the restriction and/or the icon represents the type of restriction).
  • the indication includes a textual description of the restriction and/or the icon represents the type of restriction.
  • the operation of the electronic device of displaying customized navigation routes described above with reference to method 700 optionally has one or more of the characteristics of receiving information about characteristics of respective vehicles, anonymizing a vehicle identifier, efficient route determinations, etc., described herein with reference to other methods described herein (e.g., methods 900, 1100 and 1300). For brevity, these details are not repeated here.
  • the operations in the information processing methods described above are, optionally, implemented by running one or more functional modules in an information processing apparatus such as general purpose processors (e.g., as described with respect to Figs. 1A-1B, 3, 5A-5B) or application specific chips.
  • displaying operations 702, 708, and 710 and receiving operation 704 are, optionally, implemented by event sorter 170, event recognizer 180, and event handler 190.
  • Event monitor 171 in event sorter 170 detects a contact on touch-sensitive surface 604, and event dispatcher module 174 delivers the event information to application 136-1.
  • a respective event recognizer 180 of application 136-1 compares the event information to respective event definitions 186, and determines whether a first contact at a first location on the touch-sensitive surface corresponds to a predefined event or sub-event, such as selection of an object on a user interface.
  • event recognizer 180 activates an event handler 190 associated with the detection of the event or sub-event.
  • Event handler 190 optionally utilizes or calls data updater 176 or object updater 177 to update the application internal state 192.
  • event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application.
  • Receiving Information about Characteristics of Respective Vehicles [0303] Users interact with electronic devices in many different manners, including using electronic devices to view and find geographic locations on a map.
  • a user can request directions from one geographic location to another geographic location.
  • suggested directions between locations provided to the user in response to the user’s request can be customized based on the characteristics of a user’s vehicle.
  • the embodiments described below provide ways for receiving information about the characteristics of the user’s vehicle and using the received information to provide customized routes. Receiving this information and customizing routes enhances the user’s interactions with the electronic device and reduces the amount of time needed by a user to perform operations. Reducing operational time decreases the power usage of the device and increases battery life for battery- powered devices.
  • Figs.8A-8CC illustrate exemplary ways in which an electronic device receives information about characteristics of respective vehicles in accordance with some embodiments of the disclosure.
  • Figs.8A-8CC illustrate various examples of ways an electronic device is able to perform the processes described below with respect to Fig.9, it should be understood that these examples are not meant to be limiting, and the electronic device is able to perform one or more processes described below with reference to Fig.9 in ways not expressly described with reference to Figs.8A-8CC.
  • Fig.8A illustrates electronic device 500 displaying user interface 800 (e.g., via a display device, via a display generation component, etc.). In some embodiments, user interface 800 is displayed via a display generation component.
  • the display generation component is a hardware component (e.g., including electrical components) capable of receiving display data and displaying a user interface.
  • examples of a display generation component include a touch screen display (such as touch screen 504), a monitor, a television, a projector, an integrated, discrete, or external display device, or any other suitable display device that is in communication with device 500.
  • user interface 800 is a user interface of a map application (e.g., an application in which a user is able to view geographic locations, search for locations, and/or request directions from one location to another, similar to the map application described above with respect to Fig.6A).
  • the map application is an application installed on device 500.
  • user interface 800 includes a representation of a map including the current location of the electronic device.
  • user interface 800 does not include any suggested routes or driving directions and is optionally a default user interface of the map application (e.g., in a browsing state) that includes location indicator 804.
  • user interface 800 includes settings option 802 that is selectable to display a settings user interface.
  • user interface 800 includes location indicator 804 that represents the current location of device 500 on the representation on the map.
  • device 500 displays user interface 806.
  • user interface 806 includes search field 808 for performing a search for a location or business.
  • user interface 806 includes one or more shortcuts 810 that are selectable to search for and display the respective location associated with the respective shortcut.
  • the “Home” shortcut is selectable to display the location associated with “Home”
  • the “Work” shortcut is selectable to display the location associated with “Work”
  • the “Gym” shortcut is selectable to display the location associated with “Gym”.
  • device 500 determines that an application associated with vehicle 1 (e.g., Vehicle 1 app) is not currently installed on the device.
  • an application associated with Vehicle 1 is an application external to the map application (e.g., a third-party application, an application provided by a manufacturer of Vehicle 1, etc.).
  • an application associated with Vehicle 1 is configured to receive and/or display information associated with Vehicle 1.
  • the application is able to receive information from a computer on Vehicle 1 or from a server (which in turns receive information from a computer on Vehicle 1) about one or more characteristics of Vehicle 1.
  • the application is able to receive the current fuel and/or charge level of the vehicle and/or is able to receive estimated driving range information (or determine the estimated driving range based on the current fuel and/or charge level) of the vehicle.
  • the application is able to receive and/or maintain information about other characteristics of the vehicle, such as the make a model, the color, the vehicle dimensions, the climate control status, the open or closed status of the doors, the current tire pressure, the airbag status, the emissions system status, etc.
  • the map application is able to receive information from the application associated with Vehicle 1.
  • the map application receives information about Vehicle 1 for use in providing customized routes when traveling using Vehicle 1, similar to described above with respect to method 700.
  • the map application may receive information about Vehicle 1 from other sources.
  • a user can manually provide information to the map application (e.g., manual entry from a user), the information can be embedded in a QR code (e.g., information about the vehicle itself, or information for how to communicate with a server or system to receive information about the vehicle), an API call from the map application (e.g., by the map application, by device 500, etc.) to a computer system (e.g., a computer system associated with Vehicle 1), or other ways in which a user positively opts into sharing his or her vehicle information with the map application.
  • a QR code e.g., information about the vehicle itself, or information for how to communicate with a server or system to receive information about the vehicle
  • an API call from the map application e.g., by the map application, by device 500, etc.
  • a computer system e.g., a computer system associated with Vehicle 1
  • device 500 determines that no application associated with a particular vehicle is installed on the device, then user interface 800 does not include an indication and/or button to link an application associated with a vehicle with the map application.
  • device 500 provides a way for the user to manually enter information to associate a vehicle with the map application.
  • device 500 provides a way for the user to specify information about a vehicle, e.g., the vehicle manufacture, the vehicle VIN, or other identifying information, in order for the map application to communicate with a computer system (e.g., associated with the vehicle) in order to obtain vehicle data.
  • a computer system e.g., associated with the vehicle
  • the map application and/or device 500 has determined that Vehicle 1 App (e.g., an application associated with Vehicle 1) is installed on device 500.
  • Vehicle 1 App e.g., an application associated with Vehicle 1
  • user interface 806 in accordance with a determination that the Vehicle 1 app is installed on device 500, includes indication 812.
  • indication 812 includes a description to connect the Vehicle 1 app with the map application to get customized routes and/or charging suggestions.
  • user interface 806 includes an indication that a user can enter information about their specific vehicle in order to manually link the map application to the vehicle or to access a specific vehicle’s computer system (e.g., through an API) to complete the linking process.
  • indication 812 includes button 814 that is selectable to initiate the process to link the map application with the Vehicle 1 app.
  • Vehicle 1 is an electric vehicle.
  • indication 812 is displayed only if the map application is not already linked with the Vehicle 1 app.
  • indication 812 is displayed only if the Vehicle 1 application is itself configured to provide information about Vehicle 1 (e.g., the Vehicle 1 app has been linked with Vehicle 1 and is able to receive and provide information about Vehicle 1).
  • indication 812 is optionally not displayed until such time that the Vehicle 1 app is initiated and/or linked to Vehicle 1.
  • indication 812 is displayed even if the user has manually added Vehicle 1 to the map application (optionally initiating a process to link the Vehicle 1 app with the map application will override or supplement the information manually provided to the map application by the user about Vehicle 1).
  • indication 812 can be displayed in accordance with a determination that criteria other than that the Vehicle 1 app is installed are satisfied.
  • the map application is able to receive information for a vehicle from one or more external sources, such as an application that’s installed on the same device as the map application, from an external server, from a computer system associated with a vehicle (e.g., a vehicle’s on-board computer system, such as the vehicle’s ECU), etc.
  • device 500 can display indication 812 if device 500 determines that any of these mechanisms for receiving information about the user’s vehicle are available. For example, if device 500 determines that device 500 is in communication with or able to communicate with the on-board computer system of a user’s vehicle, then device 500 can display indication 812 to link the user’s vehicle with the map application.
  • device 500 in response to a user selection of indication 812, can initiate the process to add the user’s vehicle to the map application (optionally to pair device 500 with the vehicle’s on-board computer system), as will be described in more detail below.
  • device 500 can display indication 812 without requiring the satisfaction of the criteria described above.
  • the user in response to a user selection of indication 812, can be presented with one or more options to link Vehicle 1 with the map application (e.g., present the user with the option to provide communication details to connect with a server associated with the user’s vehicle, present the user with the option to scan a QR code that provides communication details to connect with a server associated with the user’s vehicle, etc.).
  • Fig.8C illustrates an exemplary lock or wake screen user interface 816 that includes notification 818.
  • notification 818 is displayed in accordance with a determination that the Vehicle 1 app is installed on device 500.
  • notification 818 includes a description to connect the Vehicle 1 app with the map application to get customized routes and/or charging suggestions.
  • selection of notification 818 initiates a process to link the map application with the Vehicle 1 app (e.g., causes the map application to be displayed, automatically navigated to a user interface for linking the Vehicle 1 app with the map application, such as the user interface shown in Fig.8E).
  • notification 818 is displayed only if the map application is not already linked with the Vehicle 1 app.
  • notification 818 is displayed on any user interface and is not limited to only a lock or wake screen user interface.
  • notification 818 can be displayed while device 500 is displaying a system user interface (e.g., the home screen user interface, an application launching user interface, a settings user interface) or a user interface of an application.
  • notification 818 can be displayed on a notification user interface (e.g., a user interface that includes one or more active notifications).
  • notification 818 is persistent and remains displayed on the lock or wake screen user interface (optionally and on the notification user interface) until a user manually dismisses notification 818, until the user selects notification 818 and/or until the user links the Vehicle 1 app with the map application.
  • a user input 803d is received selecting button 814.
  • device 500 in response to user input 803d, device 500 initiates a process to link Vehicle 1, (e.g., through the Vehicle 1 app) with the map application, as shown in Fig.8E.
  • device 500 displays user interface 820.
  • user interface 820 is a user interface for confirming linking of Vehicle 1 (e.g., through the Vehicle 1 App) with the map application.
  • user interface 820 includes an icon 822 that represents the Vehicle 1 app (e.g., the app icon).
  • user interface 820 includes description 824 that explains that connecting Vehicle 1 (e.g., through the Vehicle 1 App) with the map application allows the map application to receive characteristics of vehicle 1.
  • user interface 820 includes button 826 and button 828.
  • button 826 is selectable to connect (e.g., add, link, register, etc.) Vehicle 1 with the map application.
  • button 828 is selectable to terminate the process to link Vehicle 1 with the map application (e.g., cancel the linking).
  • a user input 803e is received selecting button 826.
  • device 500 displays user interface 830.
  • user interface 830 includes the vehicles that are associated with the Vehicle 1 App (e.g., the application for which indication 812 was displayed).
  • a particular vehicle application can be associated with multiple vehicles and receive and provide information about multiple vehicles (e.g., if the vehicles are of the same make and model, if the vehicles are by the same manufacturer, if the application is compatible with multiple vehicles, if the application is compatible with vehicles of different makes and/or models, etc.).
  • user interface 830 includes listing 836-1 corresponding to Vehicle 1 and listing 836-2 corresponding to Vehicle 2.
  • the Vehicle 1 App is able to access and provide information about Vehicle 1 and Vehicle 2 (e.g., Vehicle 1 and Vehicle 2 are optionally the same make and/or model and/or both Vehicle 1 and Vehicle 2 are registered with the Vehicle 1 app).
  • listing 836-1 includes icon 838-1 representing Vehicle 1 and description 840-1.
  • description 840-1 includes the name of the vehicle (or optionally the make and/or model of the vehicle) and the current charge status of Vehicle 1 (and optionally the current estimated driving range).
  • listing 836-2 includes icon 838-2 representing Vehicle 2 and description 840-2 that includes the name of Vehicle 2 and the current charge status of Vehicle 2 (and optionally the current estimated driving range).
  • the names of the vehicles and the current charge statuses are optionally received from the Vehicle 1 app.
  • each listing includes an indication (e.g., indication 842-1 and indication 842-2) indicating that the respective vehicle will be added to the map application.
  • Fig.8F user input 803f is received on listing 836-2, thus de-selecting Vehicle 2 from being added to the map application, as shown in Fig.8G.
  • Only Vehicle 1 will be added to the map application (e.g., the map application will only receive information about Vehicle 1 and not Vehicle 2).
  • user input 803g is received selecting affordance 834 corresponding to a confirmation to add Vehicle 1.
  • Vehicle 1 is added to the map application and the Vehicle 1 app is linked with the map application, as shown in Fig.8H.
  • linking the Vehicle 1 app allows the map application to receive information about Vehicle 1 from a source external to the application.
  • the information is received from the Vehicle 1 app.
  • the information is received from a server external to device 500 (e.g., linking the Vehicle 1 app with the map application provided the map application with information and/or credentials to communicate with the external server).
  • a server external to device 500 e.g., linking the Vehicle 1 app with the map application provided the map application with information and/or credentials to communicate with the external server.
  • an indication such as indication 812 can be displayed for linking the Vehicle 3 app with the map application (e.g., to add Vehicle 3 to the map application and enable the map application to receive information about Vehicle 3 from the Vehicle 3 app and/or an external source).
  • indication 812 is only displayed for one application associated with a vehicle (e.g., only displayed once) and after performing the above-described linking process, a user can manually initiate the process for other vehicle applications via a settings user interface of the map application (e.g., such as user interface 848 described below).
  • a settings user interface of the map application e.g., such as user interface 848 described below.
  • user interface 848 is a settings user interface for changing and/or modifying one or more settings associated with the map application.
  • user interface 848 includes options 850, 852, 854, 856, 858, and 860 corresponding to different options and/or settings.
  • option 854 corresponds to the “My Vehicles” option and is selectable to display the vehicles that have been added to the map application.
  • user input 803i is received selecting option 854.
  • device 500 displays user interface 862, as shown in Fig.8J.
  • User interface 862 corresponds to the “my vehicles” user interface, in which the vehicles that have been registered with, added to, and/or linked to the map application are displayed.
  • user interface 862 includes listing 864 corresponding to Vehicle 1 that was added according to the linking process described above.
  • user interface 862 includes listings of vehicles that were added to the map application via a process other than the process to link the map application with an application associated with a vehicle.
  • listing 864 includes an icon representing the vehicle, the name of the vehicle (e.g., user selected name, make, and/or model), and indication 866 that indicates the current charge level and/or estimated driving range of the vehicle.
  • user input 803j is received selecting listing 864.
  • device 500 displays user interface 868.
  • User interface 868 corresponds to a settings user interface for Vehicle 1.
  • user interface 868 includes icon 870 and edit link 872.
  • icon 870 is a representation of Vehicle 1 and optionally has a visual characteristic based on a visual characteristic of Vehicle 1. For example, if Vehicle 1 is red, then the maps application is able to receive information indicating that Vehicle 1 is red from the external source (e.g., from the Vehicle 1 app), and icon 870 includes a red car icon (e.g., without the user specifying the color of the icon).
  • edit link 872 is selectable to view and/or change the color and/or pattern of Vehicle 1 (e.g., away from the automatically populated color and/or pattern based on the information received about Vehicle 1), as will be described below.
  • user interface 868 includes name field 874.
  • name field 874 is selectable to edit the name of Vehicle 1 (e.g., cause display of a soft keyboard with which the user is able to edit and/or provide a desired name).
  • name field 874 is pre-populated with a name provided by the Vehicle 1 app (e.g., the make and/or model of the car, a name selected by a user to the Vehicle 1 app, etc.).
  • user interface 868 includes charger option 876-1 and charger option 876-2.
  • Charger option 876-1 corresponds to the charging plug type of Vehicle 1 and is selectable to view and/or edit the charger types and/or available adapters, as will be described in more detail below.
  • charger option 876-2 corresponds to the charging network preference and/or compatibility with Vehicle 1, and is selectable to view and/or edit the charging networks to charge Vehicle 1 with, as will be described in more detail below.
  • user interface 868 includes app listing 878 corresponding to the application that is associated with Vehicle 1 (e.g., and linked with the map application). In some embodiments, selection of app listing 878 causes display of the application associated with Vehicle 1.
  • user interface 868 does not include app listing 878 if Vehicle 1 was added via a process other than the app linking process described above (e.g., such as via manually adding the vehicle).
  • user interface 868 includes manufacturer information 880- 1 and model information 880-2 that includes information about the make and model of Vehicle 1, respectively.
  • the make and/or model information of Vehicle 1 is received from the Vehicle 1 app and thus manufacturer information 880-1 and model information 880-2 is automatically populated upon linking the Vehicle 1 app with the map application.
  • a user input 803l is received selecting edit link 872.
  • device 500 displays user interface 882 for viewing and/or editing the visual characteristics of Vehicle 1.
  • user interface 882 includes a plurality of color options 886-1 to 886-18 that are selectable to set the color of Vehicle 1 (e.g., which is used as the color for icons that represent Vehicle 1, such as icon 884 and icon 870).
  • the color option that is selected in user interface 882 is initially automatically populated based on color information received from the Vehicle 1 app. For example, the Vehicle 1 app is able to provide the map application with information about the visual characteristics of Vehicle 1 and indicates to the map application that Vehicle 1 has a color associated with color option 886-16. Thus, color option 886-16 is automatically selected.
  • a user is able to select a different color option from the list of color options and override the color option that is provided by the Vehicle 1 application.
  • the color options that are displayed in user interface 882 are the only color options that are available for the specific make and model of the color (e.g., the map application receives all of the available color options from the Vehicle 1 app).
  • the color options that are displayed are generally available vehicle colors and are not selected for display based on the available colors for the specific vehicle. [0325] In Fig.8N, returning to user interface 868, a user input 803n is received selecting charger option 876-1.
  • device 500 in response to user input 803n, displays user interface 888, as shown in Fig.8O.
  • user interface 888 includes listing 890 and adapter option 892.
  • listing 890 indicates the default plug type of Vehicle 1.
  • the default plug type is the type of plug that is currently installed on Vehicle 1.
  • the default plug type is automatically selected based on information received from the Vehicle 1 app.
  • listing 890 is selectable to change the installed plug type (e.g., if the user performed an after-market modification of the default plug type).
  • adapter option 892 is selectable to add one or more adapter plugs to the map application.
  • An adapter plug is optionally a mechanism/apparatus that converts the default plug type to one or more other plug types.
  • Plug Type 1 may be only compatible with charging stations that accept Plug Type 1, but would not be compatible with charging stations that are only compatible with Plug Type 2.
  • a plug adapter can be used to convert Plug Type 1 to be compatible with Plug Type 2 (e.g., by changing the physical characteristics of the plug, by changing the electrical characteristics of a particular charging station to something that is compatible with Vehicle 1, etc.).
  • charger option 876-1 optionally is not displayed on user interface 868 or user interface 888 includes the default implement for use in refueling or recharging the vehicle, including an option for adding compatible adapters for the respective vehicle.
  • charger option 876-1 optionally is not displayed on user interface 868 or user interface 888 includes the default implement for use in refueling or recharging the vehicle, including an option for adding compatible adapters for the respective vehicle.
  • user input 803o is received selecting adapter option 892.
  • device 500 displays user interface 894, as shown in Fig.8P.
  • User interface 894 includes a list of adapters that are selectable to indicate to the map application the adapters that the user has possession of.
  • the list of adapters includes only adapters that are compatible with Vehicle 1 (e.g., only adapters that are compatible with the vehicle (optionally not adapters that are not compatible with the vehicle), only adapters that are compatible with the vehicle’s plug type (optionally not adapters that are not compatible with the vehicle’s plug type), etc.).
  • the list of adapters is received from the Vehicle 1 app.
  • the list of adapters includes all existing adapters for any plug type. [0328] In Fig.8P, a user input 803p is received selecting adapter option 896-2.
  • adapter 2 in response to user input 803p, is selected to be added as an available adapter for Vehicle 1, as shown in Fig.8Q (e.g., represented by the check mark icon).
  • Fig. 8Q a user input 803q is received selecting adapter 896-3 corresponding to adapter 3.
  • adapter 3 in response to user input 803q, adapter 3 is also selected to be added as an available adapter for Vehicle 1, as shown in Fig.8R. [0329]
  • Fig.8R a user input 803r is received selecting the “Done” option, thus completing the addition of Adapter 2 and Adapter 3, and dismissing user interface 894, as shown in Fig.8S.
  • user interface 888 now includes adapter listing 898-1 and adapter listing 898-2 corresponding to adapter 2 and adapter 3, respectively, that was added.
  • the map application is able to suggest charging stations that are compatible with Vehicle 1 (e.g., compatible with Plug Type 1 and/or can be made to be compatible with Plug Type 1 using Adapter 2 or Adapter 3).
  • device 500 can provide a list of different compatible adapters for vehicles other than electric vehicles. For example, a respective hydrogen vehicle may be compatible with certain fuel pump types and may require certain adapters to refuel at particular hydrogen fuel stations.
  • Fig.8T user input 803t is received selecting charger option 876-2 corresponding to charging networks.
  • device 500 displays user interface 899, as shown in Fig.8U.
  • user interface 899 includes a list of one or more charging networks that are in operation in the user’s geography (e.g., in the country, in the state, in the municipality, in the region, etc.).
  • user interface 899 includes charging network 897-1, charging network 897-2, and charging network 897-3. As shown in Fig.8U, charging network 897-3 is automatically initially populated, optionally based on information received from the Vehicle 1 App.
  • Vehicle 1 may have a pre-existing relationship with charging network 897-3 or may be compatible with charging network 897-3 (e.g., optionally only compatible with charging network 897-3).
  • charging network 897-3 may be the charging network recommended by the manufacturer of Vehicle 1.
  • a user is able to select any of the charging network listings to indicate to the map application the charging network that the user would like to use to charge Vehicle 1.
  • user input 803u is received selecting charging network 897-2.
  • the map application will suggest only charging stops for Vehicle 1 that are within charging network 897-2 (e.g., selection of a charging network selects the respective charging network as the only compatible charging network).
  • the map application in response to selection of charging network 897-2, will suggest charging stops for Vehicle 1 that are within both charging network 897-2 and charging network 897-3 (e.g., selection of a charging network toggles the respective charging network as a compatible charging network).
  • the respective vehicle is not an electric vehicle, but rather, a vehicle of a different fuel type (e.g., gasoline vehicle, plug-in hybrid, E85 vehicle, etc.)
  • charger option 876-2 optionally is not displayed on user interface 868 or user interface 899 includes options for networks of stations compatible with the respective vehicle’s fuel type (e.g., options corresponding to different gas station brands, etc.).
  • Figs.8V-8CC illustrate embodiments in which the map application displays information or suggestions based on the information received from the Vehicle 1 app (and/or defined in the vehicle settings user interface, as previously described). It is understood that although the embodiments illustrated herein describe receive information from the Vehicle 1 app, the information can be received from any source external to the map application, such as a server external to device 500.
  • device 500 determines one or more suggested routes and/or determines one or more suggested stops
  • this determination can be performed by the navigation server or by a combination of device 500 and the navigation server, the results of which are provided to device 500 for display in the user interface.
  • device 500 displays user interface 800 while Vehicle 1 is selected.
  • user interface 800 is similar to user interface 600 described in Fig.6A and includes location indicator 883.
  • location indicator 883 has a visual characteristic based on the visual characteristic of Vehicle 1.
  • location indicator 883 has the same visual characteristic as the visual characteristic of icon 884 and color option 886-16 described above in Fig.8M.
  • a user input 803v is received requesting directions from the current location to Destination 1.
  • device 500 displays one or more suggested routes.
  • suggested route 887-1 and/or suggested route 887-2 include one or more suggested stops to refuel and/or recharge Vehicle 1.
  • the current charge level of Vehicle 1 is such that Vehicle 1 has a 20 mile range.
  • the map application receives the current driving range information from the Vehicle 1 app (e.g., 20 mile range) and/or receives the current charge information from the Vehicle 1 app (e.g., 5% charge). Based on the received information, device 500 determines that a charging stop is required and includes a charging stop on one or more of the suggested routes.
  • the charging stop that is selected is within the charging network that was selected above in Fig.8U (e.g., that is optionally provided by the Vehicle 1 app) and that is compatible with the plug type of Vehicle 1 (optionally with or without using one of the available adapters).
  • the location and existence of charging stops is received from the Vehicle 1 app or from a database other than the Vehicle 1 app.
  • the suggested routes and/or suggested stops provided by device 500 can be different than those shown herein, based on whether particular charging stations are compatible with particular adapters and/or based on whether a particular charging station is within the selected charging network. For example, in Figs.6K-6L, the selected charging network is “Gigawatts” and thus the suggested stop is within the “Gigawatts” charging network, whereas the suggested stop of suggested route 887-1 is within the “Ionize” charging network (which is compatible with the adapters selected by the user in Figs.8P-8R).
  • Fig.8W illustrates an embodiment similar to Fig.6M in which a user input 803w is received requesting navigation using suggested route 887-1.
  • device 500 in response to user input 803w, enters navigation mode and displays step-by-step and/or turn-by-turn directions to navigate along suggested route 887-1 to the destination.
  • device 500 while in navigation mode, displays a representation of the vehicle that is based on the characteristics received from the external source.
  • Fig.8X illustrates an embodiment, similar to Fig.6P, in which the user has arrived at a suggested charging station. As shown in Fig.8X, the suggested charging station is within the charging network selected above in Fig.8U (e.g., the “Ionize” charging network). In Fig.8X, instructions 877 indicate the adapter that is required to connect Vehicle 1 with the charging station (e.g., “Adapter 2”).
  • Fig.8Y illustrates an embodiment, similar to Fig.6Q, in which device 500 has determined that Vehicle 1 has begun charging.
  • device 500 receives information from Vehicle App 1 that Vehicle 1 has begun charging (e.g., receives charging and/or battery level information).
  • device 500 in accordance with a determination that Vehicle 1 has begun charging, updates instructions 879 to display the amount of time remaining to charge to the suggested level.
  • information 879 includes an indication of the current charge level.
  • Fig.8Z illustrates an embodiment, similar to Fig.6Q, in which Vehicle 1 has been charged to 34%.
  • instructions 879 is updated to reflect the updated charge status. For example, in Fig.8Z, instructions 879 reads “8 minutes remaining”, which is based on the estimated time remaining to charge to 53% that is based on the charging rate and/or based on the current charge level that is received from the Vehicle 1 app.
  • Fig.8AA illustrates an embodiment, similar to Fig.6V, in which device 500 is in navigation mode and device 500 determines, based on updated charge information, that a recharging stop is required to reach the destination.
  • the map application receives, from the Vehicle 1 app, updated charge information (e.g., 10% charge) and/or updated driving range information (e.g., 20 miles, 40 miles, etc.) and determines that a recharging stop is required.
  • device 500 displays a proposed route that includes a suggested stop within the selected charging network (optionally that is compatible with the plug type of Vehicle 1).
  • the ability to link the map application to an application associated with a vehicle can be performed for a vehicle of any fuel type (e.g., gasoline vehicle, hybrid vehicle, plug-in hybrid, etc.), and the map application can receive information about characteristics of vehicles of any fuel type.
  • the map application can determine (optionally the navigation server can determine) suggested routes and/or suggested stops based on the type of fuel used by the selected vehicle (e.g., gas stations, electric vehicle charging stations, hydrogen refueling stations, E85 stations, diesel stations, etc.).
  • Figs.8BB-8CC illustrate an embodiment in which the Vehicle 1 app is installed on device 500 but is not yet linked with the map application.
  • Fig.8BB user input 803bb is received requesting directions from the current location to Destination 1 while the Vehicle 1 App is installed but not linked (e.g., Vehicle 1 is not selected and/or the map application does not have access to information about the characteristic of Vehicle 1), similar to the embodiments described in Figs.6A-6B.
  • device 500 in response to user input 803bb, displays suggested route 887-5 and suggested route 887-6. As shown in Fig.8CC, suggested route 887-5 and suggested route 887-6 are selected and/or determined without regard to the characteristics of Vehicle 1.
  • suggested route 887-5 is the fastest route from the device’s current location to Destination 1, without including any suggested stops for recharging and/or refueling
  • suggested route 887-6 is an alternative route to suggested route 887-5 that also does not include any suggested stops for recharging and/or refueling.
  • the map application is not able to receive information about the current characteristics of the Vehicle 1 and does not provide suggested stops based on current characteristics of Vehicle 1 received from an external source. It is understood, however, that the map application is able to provide customized suggested stops based on other information that is not received from the Vehicle 1 app or an external source.
  • Fig.9 is a flow diagram illustrating a method 900 of receiving information about characteristics of respective vehicles in accordance with some embodiments of the disclosure.
  • the method 900 is optionally performed at an electronic device such as device 100, device 300, and device 500 as described above with reference to Figs.1A-1B, 2-3, 4A-4B and 5A-5H. Some operations in method 900 are, optionally combined and/or the order of some operations is, optionally, changed. [0345] As described below, the method 900 provides ways to receive information about characteristics of respective vehicles. The method reduces the cognitive burden on a user when interacting with a user interface of the device of the disclosure, thereby creating a more efficient human-machine interface. For battery-operated electronic devices, increasing the efficiency of the user’s interaction with the user interface conserves power and increases the time between battery charges.
  • an electronic device 500 in communication with a display generation component (e.g., a mobile device (e.g., a tablet, a smartphone, a media player, or a wearable device), or a computer, optionally in communication with one or more of a mouse (e.g., external), trackpad (optionally integrated or external), touchpad (optionally integrated or external), remote control device (e.g., external), another mobile device (e.g., separate from the electronic device), a handheld device (e.g., external), and/or a controller (e.g., external), etc.) displays (902), via the display generation component, a map user interface of a map application, such as user interface 800 in Fig.8A (e.g., a user interface that displays a representation of a map of a given geographic location.
  • a display generation component e.g., a mobile device (e.g., a tablet, a smartphone, a media player, or a wearable device), or a computer, optionally
  • the display generation component is a display integrated with the electronic device (optionally a touch screen display), external display such as a monitor, projector, television, or a hardware component (optionally integrated or external) for projecting a user interface or causing a user interface to be visible to one or more users, etc.
  • the user interface is a user interface of a map application.
  • the map user interface is interactable by the user to view different geographic locations or change the zoom level of the map.
  • the map user interface includes a representation of a map (e.g., a representation of a geographic location) and respective information (904), such as suggested route 887-1 and suggested route 887-2 in Fig.8W (e.g., an icon that represents the electronic device and optionally indicates the determined current location of the device).
  • the respective information includes one or more routes for travelling from one location to another location.
  • the respective information is based on characteristics of a vehicle (e.g., color, shape, size, model, mileage, fuel type, etc.).
  • the respective information is based on the selected mode of transportation.
  • the map application in accordance with a determination that receiving, by the map application, information corresponding to a characteristic of a first vehicle (e.g., a current and/or real-time state or characteristic of the first vehicle) from a source external to the map application is enabled (e.g., the map application has been configured to receive information from an external source that affects the display of the directions and/or routes from the first location to the second location), the respective information is first information, wherein the first information is based on the characteristic of the first vehicle received from the source external to the map application (906), such as current driving range of Vehicle 1 in Fig.8W (e.g., the one or more proposed routes from the first location to the second location are based on the received information).
  • a characteristic of a first vehicle e.g., a current and/or real-time state or characteristic of the first vehicle
  • the respective information is first information, wherein the first information is based on the characteristic of the first vehicle received from the source external to the map application (906), such as current driving range of
  • the external source is an application associated with the first vehicle, separate from the map application, that is installed on the electronic device.
  • the external source is a server (e.g., external to the electronic device) associated with the first vehicle, that provides information to the map application.
  • the external source is another electronic device (e.g., external to the electronic device but in wired or wireless communication with the device).
  • the current characteristic of the first vehicle includes fuel information (e.g., amount of gas available, amount of charge available), estimated distance that can be traveled for the current fuel (or charge) level, the type of fuel the vehicle uses (or the type of charger required), and/or physical characteristics of the first vehicle such color, size, shape, etc.).
  • the information corresponding to the characteristic of the first vehicle is received from multiple sources that are external to the map application (e.g., multiple applications, multiple servers, etc.).
  • the information is information other than the current location of the vehicle and/or one or more geographic locations (e.g., landmarks, etc.).
  • the information includes the current location of the vehicle.
  • a particular source provides information of characteristics of multiple vehicles (e.g., an application is associated with and is able to provide information about one or more vehicles).
  • the map application is configured to receive information from multiple external sources.
  • each source is associated with a different vehicle (e.g., a first application associated with the first vehicle, a second application associated with a second vehicle, etc.).
  • the proposed routes include a proposed stop to refuel and/or recharge.
  • the proposed routes include the proposed stop because the current fuel level (or charge level) received from the external source does not allow the vehicle to reach the destination without refueling (or recharging).
  • the proposed stop depends on the type of charging station or fuel station needed to provide the vehicle with the charge or fuel required (e.g., a specific type of charging station, a specific type of gas station that provides a specific type of fuel such as diesel or E85).
  • the first information is a representation of the first vehicle, such as an icon or model of the first vehicle that reflect the physical characteristics (e.g., has color(s) and/or a shape that is representative of the first vehicle).
  • the first information is information other than location information (e.g., current location of the vehicle, starting location for navigation directions, destination location for navigation directions, landmarks, favorite locations, etc.
  • location information e.g., current location of the vehicle, starting location for navigation directions, destination location for navigation directions, landmarks, favorite locations, etc.
  • the map application for each external source for which the map application is receiving information from, the map application is able to display information based on the characteristic for the respective vehicle associated with the external source.
  • the map application is configured to receive information from a first application associated with a first vehicle, a second application associated with a second vehicle, and a first server associated with a third vehicle
  • the map application is able to display first information based on characteristics of the first vehicle received from the first application, second information based on characteristics of the second vehicle received from the second application, and third information based on characteristics of the third vehicle received from the first server.
  • the first, second, and third information are displayed concurrently or are displayed individually when the respective vehicles are selected in the map application.).
  • the respective information includes an icon that represents the user’s vehicle (e.g., at a location on the representation of the map corresponding to the device’s determined current location).
  • the icon has one or more visual characteristics based on the visual characteristics of the user’s vehicle.
  • the icon is a cartoon or caricature of the user’s vehicle.
  • the icon is a car having the same or similar color as the first vehicle and/or the same or similar shape as the first vehicle.
  • the above-described manner of displaying information based on received information on the characteristics of a particular vehicle quickly and efficiently customizes information for a particular vehicle (e.g., by displaying information that is based on the received current characteristics of the vehicle), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., without requiring the user to separately determine whether the resulting information is appropriate for the vehicle or perform additional inputs to manually edit proposed routes to include required stops to refuel or recharge), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the respective information and the first information are of a respective type, such as the current driving range in Fig.8W (e.g., the respective type of information includes navigation directions shown on the map, a representation of a vehicle on the map, etc.).
  • the respective information is second information of the respective type, wherein the second information is not based on the characteristic of the first vehicle, such as suggested route 887-5 and suggested route 887-6 not being based on the driving range of any vehicle in Fig.8CC (e.g., if the map application is not configured to receive information from the external source, then display information that is not based on a characteristic of a particular vehicle.
  • the map application displays one or more generic proposed routes from the first location to the second location. In some embodiments, the generic proposed routes do not take into account fuel or charge levels of the first vehicle.
  • a generic icon or generic model of a vehicle is displayed (as opposed to an icon that has visual characteristics based on the visual characteristics of the first vehicle).
  • the information displayed when receiving information by the map application is not enabled is the same type of information displayed when receiving information by the map application is enabled (e.g., the information is a route, but different routes, the information is an icon of a vehicle, but different icons, etc.).
  • the above-described manner of displaying information that is not based on received information about a characteristic of a vehicle quickly and efficiently provides either generic map information or customized map information, which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., by automatically providing customizing information if custom information is available, without requiring the user to perform additional inputs to enable or disable custom information), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the respective information is displayed in response to a user input corresponding to a request to display directions from a first location to a second location, such as user input 803 in Fig.8V (e.g., a request to display one or more routes and/or directions from a first geographic location to a second geographic location, and the respective information is one or more suggested routes for travelling from the first location to the second location).
  • the user input requests driving directions from the first location to the second location.
  • a user selects the first and/or second geographic location.
  • the first or second geographic location is the determined current location of the electronic device.
  • the map user interface displays the one or more determined routes from the first geographic location to the second geographic location.
  • the one or more suggested routes are displayed overlaid on the representation of the map.
  • the characteristic of the first vehicle includes a current estimated distance that the first vehicle is able to travel, such as the 20 mile range of Vehicle 1 in Fig.8W (e.g., receiving, from the source external to the map application, the estimated driving range of the first vehicle).
  • the characteristic of the first vehicle includes the current charge level or the current fuel level of the first vehicle.
  • respective information is based on the estimated driving range of the first vehicle. For example, respective information includes one or more suggested routes and the one or more suggested routes optionally includes one or more suggested stops to refuel or recharge the vehicle (e.g., if the estimated driving range is less than the travel distance of the one or more suggested routes), as described above with respect to method 700.
  • the characteristic of the first vehicle includes a type of charger compatible with the first vehicle, such as Adapter 2 in Fig.8X (e.g., receiving, from the source external to the map application, the type of chargers that can be used to charge the first vehicle).
  • Adapter 2 in Fig.8X e.g., receiving, from the source external to the map application, the type of chargers that can be used to charge the first vehicle.
  • different electric vehicle charging stations have different plugs and/or are compatible with different types of connectors.
  • different electric vehicles have different plugs and/or are compatible with different types of connectors.
  • adapters exist that allow electric vehicles to convert the plug installed on the electric vehicle to a plug type that is compatible with respective charging stations.
  • the source external to the map application provides the map application with information about what types of chargers are compatible with the first vehicle and optionally what adapters are compatible with the first vehicle (e.g., to connect to the different types of chargers).
  • the map application based on the information about what types of chargers are compatible with the first vehicle, the map application is able to suggest charging stations that use the type of chargers that are compatible with the first vehicle (e.g., via using an adapter or without requiring an adapter).
  • the map application does not suggest charging stations that do not use the type of chargers (e.g., either with or without the use of an adapter) that are compatible with the first vehicle.
  • the above-described manner of displaying information based on the type of chargers that are compatible with a particular vehicle quickly and efficiently determines the charging stations that are compatible with the first vehicle (e.g., by automatically determining whether the charging stations uses charger types that are compatible with the vehicle), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., without requiring the user to separately determine whether a suggested charging station is compatible with the user’s vehicle), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the characteristic of the first vehicle includes a vehicle type, such as the make and model of Vehicle 1 in Fig.8N (e.g., the source external to the map application provides information about a make, model, and/or color of the first vehicle).
  • the map application displays a representation of the first vehicle that is based on the make, model, and/or color of the first vehicle.
  • the representation of the first vehicle is displayed on the representation of the map at the current determined location (e.g., via one or more location sensors such as GPS) of the electronic device (e.g., traveling on a road, parked on a road, parked at a building, etc.).
  • the representation of the first vehicle is displayed at the current determined location of the first vehicle (e.g., based on location information received from the source external to the map application). For example, an icon of the first vehicle is displayed in the map user interface that has a color similar to or the same as the color of the first vehicle. In some embodiments, the icon of the first vehicle has a shape that is based on the make and model of the first vehicle.
  • the above-described manner of receiving the type of vehicle for a particular vehicle quickly and efficiently customizes information for a particular vehicle (e.g., by displaying information that is based on the type of vehicle that is selected), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient, which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the characteristic of the first vehicle includes a current charge level of the first vehicle, such as the 15% and 34% charge levels in Fig.8Y and 8Z (e.g., receiving, from the source external to the map application, the current charge level or the current fuel level of the first vehicle).
  • the respective information that is displayed includes the current charge level or current fuel level based on the information received from the source external to the map application.
  • the respective information that is displayed includes one or more suggested routes and the one or more suggested routes optionally includes one or more suggested stops to refuel or recharge the vehicle that are selected based on the current charge level or current fuel level of the first vehicle (e.g., if the current charge or fuel level will not allow the first vehicle to reach the destination without refueling or recharging), as described above with respect to method 700.
  • the above-described manner of displaying information based on the current charge level of a particular vehicle quickly and efficiently customizes information for a particular vehicle (e.g., by displaying customized routes based on whether the current charge level is enough to reach the destination), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user- device interface more efficient (e.g., without requiring the user to separately determine whether the vehicle is able to reach the destination using the suggested route), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the first information includes one or more suggested routes to travel from the first location to the second location using the first vehicle, such as suggested route 887-1 and suggested route 887-2 in Fig.8W (e.g., the respective information that is displayed includes one or more suggested routes from the first location to the second location).
  • the one or more suggested routes are selected and/or determined based on the received information for the characteristic of the first vehicle. For example, the map application receives, from the external source, the estimated driving range of the first vehicle and using the estimated driving range information, the map application may add one or more suggested stops to refuel or recharge the first vehicle.
  • the map application may suggest different routes based on the estimated driving range of the first vehicle, such as a shorter route or a route that is conducive to higher efficiency (e.g., to save fuel or charge).
  • the map application may suggest different routes based on other characteristics of the first vehicle, such as the ability to traverse certain roads (e.g., if the vehicle is too tall, too tall, or too heavy, or any other driving restriction, such as those described above with respect to method 700).
  • the above-described manner of displaying suggested routes based on received information for a particular vehicle quickly and efficiently customizes information for a particular vehicle (e.g., by receiving information about a current state of a vehicle and using the received information to select suggested routes for the vehicle), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., without requiring the user to separately determine whether the vehicle is able to travel along the route without stopping to refuel or recharge and separately looking for appropriate refueling or recharging stations), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the characteristic of the first vehicle includes a current estimated distance that the first vehicle is able to travel
  • a first suggested route of the one or more suggested routes includes a suggested stop to charge a battery of the first vehicle, such as suggested stop 885 in Fig.8W (e.g., based on the received information for the estimated driving distance for the first vehicle for the first vehicle’s current fuel or charge level
  • a suggested route includes one or more suggested stops (e.g., such as at a gas station or a charging station) to refuel or recharge the first vehicle).
  • a stop to refuel or recharge the vehicle is suggested if the vehicle would not reach the destination, would run out of fuel or charge before reaching the destination, would reach the destination with less than a threshold amount of fuel or charge (e.g., less than 5%, 10%, 15%, 20%, 25%, 30%, etc. amount of fuel or charge), and/or with less than a threshold amount of estimated driving range remaining (e.g., 5 miles, 10 miles, 15 miles, 30 miles, 50 miles, etc. of remaining driving range).
  • a threshold amount of fuel or charge e.g., less than 5%, 10%, 15%, 20%, 25%, 30%, etc. amount of fuel or charge
  • estimated driving range remaining e.g., 5 miles, 10 miles, 15 miles, 30 miles, 50 miles, etc. of remaining driving range.
  • the electronic device displays, in the map user interface, an affordance corresponding to the application associated with the first vehicle, such as button 814 in Fig.8D (e.g., before the first vehicle has been added to the map application, determining that an application associated with the first vehicle is installed on the device).
  • the application associated with the first vehicle is a third- party application (e.g., such as from the vehicle’s manufacturer).
  • the application associated with the first vehicle is able to access and display information about the first vehicle.
  • the application associated with the first vehicle has access to the first vehicle’s fuel or charge level, the first vehicle’s mileage, the first vehicle’s driving efficiency, the first vehicle’s driving history, the first vehicle’s tire pressure status, the first vehicle’s estimated driving range, and/or any other vehicle status information.
  • the map user interface includes a selectable option to link the application associated with the first vehicle with the map application.
  • the electronic device receives, via one or more input devices, a user input selecting the affordance, such as in Fig.8D.
  • the electronic device in response to receiving the user input selecting the affordance, the electronic device initiates a process to enable the map application to receive information corresponding to the characteristic of the first vehicle from the application associated with the first vehicle, such as in Figs.8E-8G (e.g., initiate a process to link the map application with the application associated with the first vehicle).
  • linking the application associated with the first vehicle with the map application enables information that is accessible from the application associated with the first vehicle to be accessible by and/or from the map application.
  • the map application receives and/or accesses the information available to the application with the first vehicle to customize the information displayed in the map user interface based on the received information.
  • the information is received from the application associated with the first vehicle.
  • the information is received from a server external to the electronic device (e.g., using information received from the first application that enables the map application to communicate with the server).
  • the electronic device while displaying the respective information, receives, from the source external to the map application, updated information about the characteristic of the first vehicle, such as the updated charge information in Fig.8AA (e.g., information about the characteristic of the first vehicle is continuously or periodically updated).
  • the map application periodically polls the source of the information for updated information.
  • the source pushes updates to the map application in response to determining that there is an update to the characteristic.
  • the electronic device in response to receiving the updated information about the characteristic of the first vehicle, updates the respective information based on the updated information about the characteristic of the first vehicle, such as the new suggested route 887-4 with a suggested stop in Fig.8AA (e.g., based on the received updated information, update the displayed information using the received updated information). For example, while displaying one or more suggested routes, if the map application receives updated information about the current driving range of the first vehicle, the map application changes the suggested routes to take into account any changes in the driving range (e.g., if the driving range decreases, a suggested stop may be added to the suggested routes).
  • the device does not update the respective information based on the updated information.
  • the device quickly and efficiently provides up-to-date information, which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user- device interface more efficient (e.g., without requiring the user to perform additional inputs to refresh the information displayed to the user based on updated information), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the updated information about the characteristic of the first vehicle includes a current charge level of the first vehicle and the updated information about the characteristic of the first vehicle is received while the first vehicle is being charged, such as the 15% and 34% charge level in Figs.8Y-8Z (e.g., the respective information is the current charge level or current fuel level of the first vehicle and while the first vehicle is being refueled or recharged, the map application is able to receive the updated fuel or charge levels and display the updated fuel or charge levels (and/or update estimated fuel or charge levels that are associated with certain steps of a route, and/or determine the estimated time for refueling or recharging the vehicle, and/or update the expected time of arrival at the destination based on the fueling or charging rate)).
  • the map application is able to receive the updated fuel or charge levels and display the updated fuel or charge levels (and/or update estimated fuel or charge levels that are associated with certain steps of a route, and/or determine the estimated time for refueling or recharging the vehicle, and/or update the expected time of
  • updating the respective information based on the updated information about the characteristic of the first vehicle is performed while providing navigation directions for the first vehicle, and includes updating the navigation directions based on the updated information about the characteristic of the first vehicle, such as the new proposed route with a new charging stop in Fig.8AA. (e.g., while navigating along a suggested route such that step-by-step navigation directions are displayed, updating or modifying the navigation directions based on the updated information).
  • updating the navigation directions for the vehicle is performed while providing navigation directions for the first vehicle, and includes updating the navigation directions based on the updated information about the characteristic of the first vehicle, such as the new proposed route with a new charging stop in Fig.8AA. (e.g., while navigating along a suggested route such that step-by-step navigation directions are displayed, updating or modifying the navigation directions based on the updated information).
  • one or more stops may be added to the navigation directions for the vehicle to recharge or refuel.
  • the above-described manner of receiving updated information as the vehicle is navigating along a route quickly and efficiently monitors the state of the vehicle to determine whether the route should be updated (e.g., by automatically receiving updated information and modifying the navigation directions if the updated information suggests that the directions should be modified), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., without requiring the user to separately determine whether the navigation directions provided to the user need to be modified and performing additional inputs to manually modify the route or trigger a refresh of the suggested directions), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • updating the navigation directions based on the updated information about the characteristic of the first vehicle includes adding a suggested stop to the navigation directions, such as in Fig.8AA (e.g., adding one or more suggested stops at a gas station or charging station if, based on the updated information, the device determines that the first vehicle will not reach the destination without refueling or recharging (or optionally will reach the destination with less than a threshold amount of fuel or charge (e.g., 5%, 10%, 15%, 20%, 25%, 30%, etc. amount of fuel or charge) or less than a threshold amount of remaining driving range (e.g., 5 miles, 10 miles, 15 miles, 30 miles, 50 miles, etc. of remaining driving range)).
  • a threshold amount of fuel or charge e.g., 5%, 10%, 15%, 20%, 25%, 30%, etc. amount of fuel or charge
  • a threshold amount of remaining driving range e.g., 5 miles, 10 miles, 15 miles, 30 miles, 50 miles, etc. of remaining driving range
  • the operation of the electronic device of receiving information about characteristics of respective vehicles described above with reference to method 900 optionally has one or more of the characteristics of displaying customized navigation routes, anonymizing a vehicle identifier, efficient route determinations, etc., described herein with reference to other methods described herein (e.g., methods 700, 1100 and 1300). For brevity, these details are not repeated here.
  • the operations in the information processing methods described above are, optionally, implemented by running one or more functional modules in an information processing apparatus such as general purpose processors (e.g., as described with respect to Figs. 1A-1B, 3, 5A-5B) or application specific chips.
  • displaying operation 902 is, optionally, implemented by event sorter 170, event recognizer 180, and event handler 190.
  • Event monitor 171 in event sorter 170 detects a contact on touch-sensitive surface 604, and event dispatcher module 174 delivers the event information to application 136-1.
  • a respective event recognizer 180 of application 136-1 compares the event information to respective event definitions 186, and determines whether a first contact at a first location on the touch-sensitive surface corresponds to a predefined event or sub-event, such as selection of an object on a user interface.
  • event recognizer 180 activates an event handler 190 associated with the detection of the event or sub-event.
  • Event handler 190 optionally utilizes or calls data updater 176 or object updater 177 to update the application internal state 192.
  • event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application.
  • GUI updater 178 it would be clear to a person having ordinary skill in the art how other processes can be implemented based on the components depicted in Figs.1A-1B.
  • Anonymizing Vehicle Identifiers [0389] Users interact with electronic devices in many different manners, including using electronic devices to view directions from one geographic location to another geographic location.
  • certain geographic locations implement driving restrictions in which certain cars may be prohibited from driving in a restricted region based on one or more characteristics of the user’s vehicle.
  • a geographic location may implement a driving restriction based on the values of a vehicle’s license plate.
  • the electronic device provides an anonymized version of the vehicle’s license plate to a navigation server to receive navigation routes that are customized for the particular vehicle (e.g., that take into account the driving restriction). The embodiments described below provide ways for anonymizing the vehicle’s license plate and transmitting the anonymized license plate to the navigation server to preserve the user’s privacy.
  • Figs.10A-10P illustrate exemplary ways in which a vehicle identifier is anonymized in accordance with some embodiments of the disclosure. The embodiments in these figures are used to illustrate the processes described below, including the processes described with reference to Fig.11.
  • Figs.10A-10P illustrate various examples of ways an electronic device is able to perform the processes described below with reference to Fig.11, it should be understood that these examples are not meant to be limiting, and the electronic device is able to perform one or more processes described below with reference to Fig.11 in ways not expressly described with reference to Figs.10A-10P.
  • Fig.10A illustrates electronic device 500 displaying user interface 1000 (e.g., via a display device, via a display generation component, etc.).
  • user interface 1000 is displayed via a display generation component.
  • the display generation component is a hardware component (e.g., including electrical components) capable of receiving display data and displaying a user interface.
  • examples of a display generation component include a touch screen display (such as touch screen 504), a monitor, a television, a projector, an integrated, discrete, or external display device, or any other suitable display device that is in communication with device 500.
  • user interface 1000 is a user interface of a map application (e.g., similar to user interface 800 described above with respect to Fig.8A).
  • the map application is an application installed on device 500.
  • user interface 1000 includes a representation of a map including the current location of the electronic device.
  • user interface 1000 does not include any suggested routes or driving directions and is optionally a default user interface of the map application (e.g., in a browsing state) that includes location indicator 1002 that represents the current location of device 500 on the representation on the map.
  • device 500 also displays user interface 1004.
  • user interface 1004 includes search field 1006 for performing a search for a location or business.
  • user interface 1004 includes one or more shortcuts 1050 that are selectable to search for and display the respective location associated with the respective shortcut.
  • the one or more shortcuts 1050 can include a “Home” shortcut that is optionally selectable to display the location associated with “Home”, a “Work” shortcut that is optionally selectable to display the location associated with “Work”, and a “Gym” shortcut that is optionally selectable to display the location associated with “Gym”.
  • a driving restriction corresponds to a restriction that defines that a certain set of vehicles may travel without restriction and a second set of vehicles are restricted from travel.
  • other restrictions are possible (e.g., a first set of vehicles must follow a certain set of rules or regulations while a second set follows a different set of rules or regulations, or all vehicles with a certain characteristic(s) are restricted from travel, etc.).
  • a restriction can exist in which odd numbered license plates (e.g., vehicles with license plates that end in an odd number) are prohibited from driving in a particular location during particular times and dates while even numbered license plates (e.g., vehicles with license plates that end in an even number) are not prohibited from driving at any time (or are prohibited from driving in the particular location during other times).
  • odd numbered license plates e.g., vehicles with license plates that end in an odd number
  • even numbered license plates e.g., vehicles with license plates that end in an even number
  • other vehicle identifiers are possible, such as the vehicle identification number (VIN).
  • a driving restriction can be that vehicles over a particular gross weight are prohibited from driving on a particular highway during business hours, while vehicles under the gross weight threshold are not prohibited from driving on the highway.
  • a restricted region is a geographic area in which a respective driving restriction applies. For example, if a driving restriction indicates that odd numbered license plates are prohibited from driving in a particular geographic area, but even numbered license plates are not prohibited from driving in the particular geographic area, then that entire geographic area in which the restriction applies is optionally referred to as a restricted region.
  • user interface 1004 includes indication 1008 (e.g., sharing similar features as indication 812 described above with respect to Fig.8B).
  • indication 1008 includes a description to add license plate information to the map application.
  • indication 1008 includes button 1010 that is selectable to initiate the process to add license plate information to the map application.
  • indication 1008 is displayed in accordance with a determination that device 500 is at or near a restricted region that prohibits vehicle based on the license plate numbers of the vehicles (e.g., in the restricted region or within 10 miles, 30 miles, 50 miles, 100 miles, etc. of a restricted region). In some embodiments, indication 1008 is displayed if the map application does not yet have any license plate information.
  • indication 1008 is no longer shown in user interface 1004. In some embodiments, indication 1008 is displayed even if the user has previously added license plate information to the map application.
  • a user is able to add license plate information to the map application via a settings user interface for the map application (e.g., without requiring indication 1008 be displayed in user interface 1004). For example, a user is able to initiate the process to add a license plate by adding a vehicle to the map application via a user interface for managing vehicles that have been added to the map application, similar to the user interface 862 described above with respect to Fig.8J.
  • user interface 862 can include one or more options for adding vehicles, editing vehicles, and/or deleting vehicles from the map application.
  • a user is able to initiate a process to add a vehicle to the map application and provide the license plate information for the added vehicle (e.g., similar to the process for adding a license plate to the map application in response to selection of button 1010, described below).
  • providing the map application with license plate information allows the electronic device (e.g., device 500) to display one or more suggested routes based on whether the user’s vehicle is prohibited or not prohibited from traveling in the restricted region, similar to the process described above with respect to method 700.
  • the suggested routes are determined by transmitting a request for navigation routes to a navigation server (e.g., routing server) and receiving, in return, one or more potential navigation routes.
  • the navigation server is able to receive anonymized license plate information (or other anonymized vehicle identifiers, such as an anonymized VIN number, an anonymized serial number, etc.) and provide navigation routes based on whether the provided anonymized vehicle identifier falls within the restriction (e.g., the vehicle is prohibited from driving in the restricted region) or outside of the restriction (e.g., the vehicle is not prohibited from driving in the restricted region).
  • device 500 is able to protect the user’s privacy by modifying one or more values of the user’s vehicle identifier (e.g., license plate, VIN number, etc.), thus anonymizing the vehicle identifier, before transmitting an anonymized vehicle identifier to the navigation server.
  • vehicle identifier e.g., license plate, VIN number, etc.
  • the vehicle identifier information provided by the user e.g., the un-anonymized license plate, the actual license plate number, etc.
  • the vehicle identifier information provided by the user is stored on device 500 and is never transmitted away from device 500.
  • the vehicle identifier information provided by the user is deleted from device 500 after the anonymized vehicle identifier is generated (e.g., in response to generating the anonymized license plate or in response to transmitting the anonymized licensed plate to the navigation server.)
  • user input 1003a is received selecting button 1010.
  • device 500 in response to user input 1003, device 500 initiates a process to add license plate information to the map application, as shown in Fig.10B.
  • device 500 displays user interface 1012.
  • User interface 1012 is optionally a splash page or introduction page for adding license plate information to the map application.
  • user interface 1012 can include introduction 1014 that describes the process of providing license plate information to the map application and/or the benefits of providing license plate information to the map application.
  • user interface 1012 includes button 1016 that is selectable to continue the process to add license plate information to the map application.
  • user interface 1012 includes button 1018 that is selectable to terminate the process to add license plate information to the map application.
  • a user is able to initiate the process via a settings user interface for the map application.
  • user input 1003b is received by a user selecting button 1016.
  • device 500 in response to user input 1003b, continues the process to add license plate information to the map application and displays user interface 1020 as shown in Fig.10C.
  • user interface 1020 includes one or more options for selecting the geographic region in which the vehicle is registered. For example, option 1022-1 corresponds to region 1, option 1022-2 corresponds to region 2, option 1022-3 corresponds to region 3, etc.
  • different geographic regions can have different license plate patterns or license plate values and providing the map application with the respective region in which the vehicle is registered allows the map application to verify that a license plate is valid (e.g., has the correct number of digits, has valid values for respective digits, etc.).
  • device 500 prioritizes or otherwise visually emphasizes one or more regions based on the current location of device 500. For example, in Fig.10C, device 500 determines, via one or more location determination processes (e.g., GPS data, cellular tower triangulation, etc.), that device 500 is located in region 1. Thus, in accordance with a determination that device 500 is located in region 1, user interface 1020 displays option 1022-1 corresponding to region 1 at a location on user interface 1020 separate from the options for other regions, as shown in Fig.10C. Thus, device 500 is able to suggest a region to the user by displaying region 1 as the first option visually distinguished from the other regions, thereby increasing the efficiency of the device by emphasizing the more likely option to the user.
  • location determination processes e.g., GPS data, cellular tower triangulation, etc.
  • a user input 1003c is received by selecting option 1022-2 corresponding to region 2.
  • device 500 displays user interface 1024.
  • user interface 1024 is a user interface for entering a license plate number.
  • user interface 1024 includes entry 1026 for entering a license plate number and entry 1028 for selecting the vehicle’s fuel type.
  • device 500 is able to automatically determine that vehicles registered in region 2 have the same first character and thus device 500 automatically populates entry 1026 with the first character 1030 (e.g., a “beta” character).
  • device 500 can set the number of digits of a license plate or restrict the available values for respective digits based on the license plate pattern for the selected region.
  • Fig.10D illustrates user interface 1024 including entry 1026 corresponding to the license plate number and entry 1028 corresponding to the fuel type, more or fewer entries are possible and both entries need not be displayed. For example, if a geographic region considers a vehicle’s license plate number, but does not consider a vehicle’s fuel type when making a driving restriction determination, then user interface 1024 can include only a single entry for entering a license plate number without including an entry for providing a fuel type.
  • Fig.10E illustrates an alternative embodiment in which user input 1003e is received selecting option 1022-1 corresponding to region 1.
  • region 1 has a different license plate pattern than region 2.
  • device 500 displays user interface 1024 with entry 1026 automatically populated with first character 1032 (e.g., a “theta” character) that is different than first character 1030, as shown in Fig.10F.
  • first character 1032 e.g., a “theta” character
  • license plates in region 1 all have “theta” as the first character
  • license plates in region 2 all have “beta” as the first character. It is understood that device 500 is able to adapt to any license plate pattern for any geographic region and automatically populate one or more characters if respective digits of a license plate are fixed for a respective region.
  • device 500 based on the determination that device 500 is located in region 1, device 500 automatically selects option 1022-1 corresponding to region 1 as the region of registration for the vehicle being added. In such embodiments, device 500 does not display user interface 1020 and, instead, proceeds to user interface 1024 as if option 1022-1 corresponding to region 1 were selected.
  • a user input 1003f is received by a user selecting entry 1026.
  • device 500 displays virtual keyboard 1036 for entering characters into entry 1026, as shown in Fig.10G.
  • a user input 1003g is received selecting entry 1028.
  • device 500 displays user interface 1038, as shown in Fig.10H.
  • user interface 1038 includes one or more options corresponding to different fuel types.
  • option 1040-1 corresponds to a gasoline fuel type
  • option 1040-3 corresponds to a hybrid fuel type.
  • the options are scrollable to change the option that is currently selected.
  • a user is able to select the fuel type or power type for the user’s vehicle.
  • a vehicle’s fuel type can determine whether one or more sets of driving restriction rules apply to the vehicle. For example, a first set of rules may apply to cars with a gasoline fuel type while a different set of rules may apply to electric vehicles.
  • a user input 1003h is received by a user selecting option 1044 to complete the process for adding the license plate to the map application.
  • device 500 in response to user input 1003h, displays user interface 1025, as shown in Fig.10I.
  • user interface 1025 includes entry 1026 and entry 1028 populated with the user-provided values to confirm the license plate and fuel type details.
  • user input 1003i is received corresponding to a confirmation of the license plate and fuel type details.
  • device 500 in response to user input 1003i, adds the respective vehicle with the respective license plate and fuel type to the map application, and, optionally, provides a notification indication (e.g., pop-up 1048), such as shown in Fig.10J.
  • device 500 displays user interface 1000 corresponding to the map application.
  • pop-up 1048 that indicates that the vehicle has been successfully added to the map application.
  • indication 1008 is no longer shown in user interface 1000.
  • indication 1008 is only shown if the user has not previously added a license plate to the map application.
  • a user is optionally able to initiate the process to add a license plate to the map application (e.g., add another license plate) via a settings user interface for the map application (e.g., similar to user interface 848 and/or 862 as described above with respect to Figs.8I-8J).
  • a process for providing license plate information to the map application e.g., adding a license plate to the map application
  • the same or a similar process can be performed for adding other types of vehicle identifiers and/or vehicle characteristics to the map application.
  • a user input 1003k is received requesting directions to Destination 1 (e.g., represented by icon 1058 in user interface 1000) while the currently active vehicle has a license plate of “ ⁇ B32F92”.
  • a user is able to select the currently selected vehicle from a list of vehicles.
  • characteristics of the currently selected vehicle is used to determine one or more suggested navigation routes, as discussed above with respect to methods 700 and 900.
  • device 500 determines one or more suggested routes for the selected vehicle.
  • determining one or more suggested routes for the selected vehicle includes transmitting a request for routes to a navigation server or routing server.
  • the request for routes can include starting location and destination location information.
  • the request for routes can include the license plate number of the vehicle for which routes are requested.
  • certain geographic regions can have one or more driving restrictions.
  • the one or more driving restrictions are based on one or more characteristics of the vehicle seeking to travel within the restricted region.
  • the examples described herein illustrate a driving restriction that uses the values of a vehicle’s license plate to define whether a vehicle is prohibited or not prohibited from traveling within the restricted region during the restricted time period (although it is understood that other types of driving restrictions are possible). It is understood, however, that although the example illustrated herein is based on the vehicle’s license plate, a restriction can be based on any characteristic or any identifier of a vehicle and device 500 can determine one or more routes and/or perform the below-described anonymization process.
  • a license plate number e.g., a license plate number
  • device 500 anonymizes the user’s vehicle identifier to generate an anonymized vehicle identifier that is transmitted to the navigation server and safeguards the user’s actual vehicle identifier information within device 500.
  • Fig.10L illustrate an exemplary method 1060 of anonymizing a license plate.
  • an electronic device receives driving restriction ruleset 1062 and determines, based on driving restriction ruleset 1062, the portions of the license plate that are relevant to the respective driving restriction.
  • driving restriction ruleset 1062 is a simplified ruleset that has been generated from a full ruleset (e.g., as will be described in further detail below with respect to Figs.10N-10O).
  • driving restriction ruleset 1062 is a signed and encrypted package, as will be described in further detail below with respect to Figs.10N-10O.
  • a driving restriction ruleset 1062 includes one or more rules that define which license plates are prohibited from driving in a restricted region and which license plates are not prohibited from driving in the restricted region.
  • a driving restriction ruleset can include a rule that indicates that odd license plates are prohibited from driving in the restricted region and even license plates are not prohibited from driving in the restricted region.
  • step 1064 determines that a respective portion of the license plate is relevant to the respective driving restriction if the respective portion of the license plate can affect the determination of whether the vehicle is prohibited or not prohibited from driving in the restricted region.
  • step 1064 determines that a respective portion of the license plate is relevant to the respective driving restriction if a rule in the driving restriction ruleset 1062 defines two different groups of values for the respective portion of the license plate (optionally without indicating whether the groups are prohibited or are not prohibited from driving in the restriction region). For example, if a respective rule indicates that odd license plates are prohibited while even license plates are not prohibited, then at step 1064, the electronic device can determine that the last digit of the license plate is relevant (e.g., and optionally the other digits are not relevant, if there are no other rules in driving restriction ruleset 1062).
  • step 1064 the electronic device can determine that the last digit of the license plate is relevant (e.g., and optionally the other digits are not relevant, if there are no other rules in driving restriction ruleset 1062).
  • method 1060 processes the relevant portions of the license plate separately from the not relevant portions of the license plate. For example, relevant portions 1068 are processed at step 1072 and not relevant portions 1070 are processed at step 1074.
  • the electronic device determines the set of valid values for the respective portion of the license plate that are within the same set as the user’s actual license plate. For example, if a respective rule indicates that a first set for the last digit of a license plate includes only even numbers and a second set includes only odd numbers, at step 1072, the device can determine whether the last digit of the user’s license plate is even or odd. If the last digit is even, then the device optionally determines that the last digit of the user’s license plate is within the “even” group and that the set of values that includes the user’s actual license plate consists of even values.
  • the device optionally determines that the last digit of the user’s plate is within the “odd” group and that the set of valid values that includes the user’s actual license plate consists of odd values. [0417] Based on this determination, at step 1076, the device is able to determine that, to maintain the same type of restriction, the device should select a value from the respective set of values that includes the value of the respective digit in the user’s actual license plate. Thus, at step 1076, the electronic device selects a value from the respective set of values that includes the value of the respective digit in the user’s actual license plate.
  • the device For example, if the last digit of the user’s actual license plate is odd, then the device optionally chooses an odd value for the last digit of the anonymized license plate. On the other hand, if the last digit of the user’s actual license plate is an even number, then the device optionally chooses an even value for the last digit of the anonymized license plate. In some embodiments, the selection is performed randomly (e.g., randomly selecting a value from the set of values). In some embodiments, the selected values are different from the original value of the respective portion of the actual license plate.
  • the selected values are the same as the original value of the respective portion of the actual license plate (e.g., if the set of values includes only one value – the actual value of the respective portion of the actual license plate).
  • step 1076 is performed for each relevant portion of the license plate.
  • values for the not relevant portions 1070 of the license plate are selected.
  • the electronic device is able to select amongst all valid values for the respective portion of the license plate. Thus, the device need not determine multiple different sets of values to select amongst (e.g., as it does for relevant portions 1068, at step 1072).
  • the set of values to select from includes all valid values for the respective portion of the license plate.
  • the electronic device need only select from the set of valid values, without regard to whether the values are within any particular set of values.
  • the device optionally randomly selects amongst all possible valid values.
  • the selected values are different from the original value of the respective portion of the actual license plate.
  • the selected values are the same as the original value of the respective portion of the actual license plate.
  • step 1074 is performed for each portion of the license plate that is not relevant to the restriction.
  • the electronic device optionally generates the anonymized license plate by merging the selected values into a single anonymized license plate.
  • the anonymized license plate is transmitted to the routing or navigation server when a user requests navigation routes.
  • method 1060 described above is performed in response to a request for navigation routes. For example, method 1060 is performed every time the user requests routes and the anonymized license plate is discarded after completion of the request. In some embodiments, method 1060 is performed periodically (e.g., every day, every 30 days, every year, etc.).
  • method 1060 is performed every time the electronic device receives a set of rules (e.g., from a rules server, from navigation server, etc.). In some embodiments, method 1060 is performed every time the electronic device determines that the set of rules has changed.
  • Fig.10M illustrates an example method of generating an anonymized license plate with an example driving restriction ruleset.
  • driving restriction ruleset 1062 includes a first rule that asks whether the last digit of the license plate is either a 3 or an 8, and a second rule that asks whether the second digit of the license plate is a letter within the range of A-F or O-T.
  • the electronic device determines from the first rule and the second rule that the relevant portions 1068 of the license plate consist of the second digit and the last digit. As shown, because the first rule asks whether the last digit is a 3 or 8, the electronic device is able to determine that the value of the last digit of the license plate is a factor in determining whether a vehicle is prohibited or not prohibited from driving in a restricted region. Thus, the electronic device optionally determines that the last digit is relevant to the driving restriction.
  • the electronic device is able to determine that the value of the second digit of the license plate is a factor in determining whether a vehicle is prohibited or not prohibited from driving in a restricted region.
  • the electronic device optionally determines that the second digit is relevant to the driving restriction.
  • relevant portions 1068 includes the second digit of the license plate and the last digit of the license plate.
  • the electronic device optionally determines that not relevant portions 1070 includes the first and third through sixth digits of the license plate.
  • the electronic device determines the set of values within which to select values for the anonymized license plate.
  • the electronic device determines that the values for the second digit are organized into two sets: a first set that includes the values A-F and O-T (e.g., the set of values that fall “within” the second rule), and a second set that includes the values G-M and U-Z (e.g., the set of values that fall “outside” of the second rule).
  • the electronic device determines which of the sets of values is the set from which to select values for the anonymized license plate. As described above, to maintain the same restriction as the actual license plate, the electronic device selects from the set of values that includes the actual value of the respective portion of the actual license plate. Thus, because the second digit of the actual license plate is a “B”, the value of the second digit of the actual license plate falls “within” the second rule.
  • the electronic device determines that the set of values to select from 1080 for the second digit is the set of values that falls “within” the second rule (e.g., the set that includes the values A-F and O-T).
  • the electronic device optionally determines that the values for the last digit are organized into two sets: a first set that includes the values 3 and 8 (e.g., the set of values that fall “within” the first rule), and a second set that includes the values 0-2, 4-7, and 9 (e.g., the set of values that fall “outside” of the first rule).
  • the electronic device After determining the sets of values for the first rule, the electronic device determines which of the sets of values is the set from which to select values for the anonymized license plate. As described above, to maintain the same restriction as the actual license plate, the electronic device selects from the set of values that includes the actual value of the respective portion of the actual license plate. Thus, because the last digit of the actual license plate is a “2”, the value of the last digit of the actual license plate falls “outside” the first rule. Thus, the electronic device determines that the set of values to select from 1080 for the last digit is the set of values that falls “outside” of the first rule (e.g., the set that includes the values 0-2, 4- 7, and 9).
  • the electronic device selects (optionally randomly) a value from within the respective sets.
  • the electronic device selects “Q” 1084-1 from the set of values that includes A-F and O-T.
  • the selected value for the second digit is treated the same as the actual value of the second digit of the actual license plate and thus maintains the same restriction state as the actual license plate while simultaneously concealing the actual value of the second digit of the user’s actual license plate.
  • the electronic device selects “6” 1084-2 from the set of values that includes 0-2, 4, 7, and 9.
  • the selected value for the last digit is treated the same as the actual value of the last digit of the actual license plate and thus maintains the same restriction state as the actual license plate while simultaneously concealing the actual value of the last digit of the user’s actual license plate.
  • the electronic device selects from within a set of all valid values for the not relevant portions of the license plate. For example, the electronic device selects from within the set of all valid values for the first digit, for the third digit, the fourth digit, the fifth digit, and the sixth digit of the license plate.
  • the electronic device selects “ ⁇ ” for the first digit, “G” for the third digit, “6” for the fourth digit, and “Y” for the fifth digit.
  • the selection is a random selection amongst the valid values.
  • selecting a random value for a respective digit can result in selecting the same value (e.g., the first digit remained the same), or can result in selecting a letter when the original value was a letter (e.g., the selected value for the third digit is “G” when the original value for the third digit is a “3”, assuming, for example, that both letters and numbers are valid values for the third digit), or vice versa.
  • step 1078 After performing step 1074 and/or step 1076 and selecting anonymized values for all portions of a license plate (e.g., for all digits of a license plate), at step 1078, the electronic device merges all of the anonymized values into a singular anonymized license plate.
  • the first digit of the anonymized license plate is “ ⁇ ” (e.g., selected in step 1074), the second digit is “Q” (e.g., selected in step 1076), the third digit is “G” (e.g., selected in step 1074), the fourth digit is a “6” (e.g., selected in step 1074), the fifth digit is a “2” (e.g., selected in step 1074), the sixth digit is a “Y” (e.g., selected in step 1074), and the last digit is a “6” (e.g., selected in step 1076), thus resulting in a full anonymized license plate 1086 of “ ⁇ QG62Y6”.
  • Fig.10N illustrates an exemplary method 1090 of validating a driving restriction ruleset.
  • method 1090 is performed at a server, such as a rules validation server.
  • a rules validation server is optionally a server that receives a set of rules, determines whether the rules satisfy or violate certain criteria, and signs and/or encrypts the rules if the rules are validated.
  • validating a driving restriction ruleset includes determining whether the driving restriction ruleset violates certain criteria (e.g., or whether a driving restriction ruleset satisfies certain criteria).
  • a rules validation server receives a full driving restriction ruleset 1092 and determines whether the ruleset violates privacy criteria.
  • full driving restriction ruleset 1092 include one or more rules that define the set of vehicles that are prohibited from driving in the restricted region and the set of vehicles that are not prohibited from driving in the restricted region.
  • the full driving restriction ruleset 1092 includes an indication of whether a respective set of values are prohibited from driving in the restricted region and whether a second respective set of values are not prohibited from driving in the restricted region.
  • the full driving restriction ruleset 1092 optionally includes more information (e.g., more definitions, more rules, etc.) than the simplified driving restriction ruleset (e.g., such as driving restriction ruleset 1062 described above with respect to Figs.10L-10M).
  • step 1094 includes step 1096 and step 1098.
  • determining whether full driving restriction ruleset 1092 violates the privacy criteria includes determining the relevant portions of the license plate implicated by the rules (step 1096) and determining whether there are more than a threshold number of relevant portions (step 1098).
  • the rules validation server determines, from the full driving restriction ruleset 1092, the portions of the license plate that are relevant to the restricted region. In some embodiments, determining the relevant portions is similar to the process described above with respect to step 1072, the details of which will not be repeated here for brevity.
  • the validation server determines whether there are more than a threshold number of portions that are relevant to the restricted region. If there are more than the threshold number of portions, then the privacy criteria are optionally violated, and if there are less than the threshold number of portions, then the privacy criteria is optionally not violated.
  • the threshold number of portions is a third of the digits of the license plate, half of the digits, two thirds of the digits, three quarters of the digits, all of the digits, etc.
  • the validation server determines that full driving restriction ruleset 1092 indicates that all seven digits of the license plate are relevant to the driving restriction, then the privacy criteria is optionally violated.
  • a driving restriction ruleset indicates that all digits are relevant, then there exists a risk that the user’s privacy will be violated.
  • the anonymization process described above may not sufficiently anonymize the user’s license plate to ensure that the user’s identity is not revealed and/or the user’s privacy is not violated.
  • a driving restriction ruleset indicates that all digits are relevant, then it could indicate that the driving restriction ruleset has been maliciously altered by a unvalidated entity.
  • the driving restriction ruleset may be defective as a result of an error in transmission or the driving restriction ruleset may have been hacked in an effort to cause devices to transmit user’s full license plates to an unvalidated entity (e.g., a malicious entity).
  • the validation server can perform privacy validation steps other than those illustrated in method 1090.
  • the validation server can determine whether the rules define a set of values for a respective portion of a license plate with less than a threshold number of valid values. For example, if a respective rule defines a set of values to only include one value, then when performing the anonymization process, an electronic device would be unable to properly anonymize the user’s license plate. For example, if a ruleset indicates that two thirds of the digits of a license plate are relevant and for each of those digits, every set of values only includes one value, then the anonymizing process described above would result in the exact same value for two thirds of the digits. Thus, the result would be an anonymized license plate that is still substantially the same as the original license plate such that the user’s privacy would be violated.
  • the rules validation server can determine that the full driving restriction ruleset 1092 violates the privacy criteria. [0432] Returning to step 1098, if the rules validation server determines that there are more than a threshold number of relevant portions (e.g., “Yes” branch), then the privacy criteria is violated, but if there are not more than the threshold number of relevant portions (e.g., “No” branch), then the privacy criteria is not violated. In some embodiments, if the privacy criteria is violated, then at step 1099, the rules validation server rejects the full driving restriction ruleset 1092.
  • a threshold number of relevant portions e.g., “Yes” branch
  • the rules validation server rejects the full driving restriction ruleset 1092.
  • rejecting the full driving restriction ruleset 1092 includes discarding the full driving restriction ruleset 1092, forgoing generating a simplified driving restriction ruleset from the full driving restriction ruleset 1092, and/or forgoing signing and/or encrypting the full or simplified driving restriction ruleset.
  • a driving restriction ruleset is not validated (e.g., is rejected)
  • devices that depend on receiving a validated ruleset e.g., such as the electronic devices described in Figs.10L-10M
  • the electronic device optionally forgoes anonymizing a user’s license plate and forgoes providing customized navigation routes to the user.
  • the electronic device optionally only provides suggested routes that are not customized (e.g., without regard to whether a driving restriction applies to the user’s vehicle), such as described above with respect to Fig.6X.
  • the rules validation server accepts the ruleset.
  • accepting the ruleset includes generating a simplified ruleset based on the full ruleset.
  • the simplified ruleset defines the sets of values that are treated differently for the relevant portions of a license plate, similar to driving restriction ruleset 1062 described above with respect to Figs.10L-10M.
  • the rules validation server signs the simplified ruleset at step 1095.
  • signing the simplified ruleset includes encrypting the simplified ruleset using a private key of the rules validation server.
  • the electronic device e.g., such as device 500
  • the electronic device is able to decrypt the simplified ruleset using the public key of the rules validation server.
  • successfully decrypting the simplified ruleset using he public key of the rules validation server indicates that the rules are genuine and that they have been validated by the rules validation server (e.g., such that it is safe to use for anonymizing license plates to generate customized routes).
  • Fig.10O illustrates an exemplary block diagram of ecosystem 1093, including the servers and/or devices and their interactions during the processes of validating rules, generating anonymous license plates, and providing navigation routes.
  • ecosystem 1093 includes rules server 1091, validation server 1087 (e.g., rules validation server), navigation server 1083 (e.g., routing server) and client electronic device 1081 (e.g., device 500). It is understood that any of the servers illustrated herein can be combined into a single server.
  • rules server 1091 is a rules repository server in which the full driving restriction ruleset 1089 is maintained and/or stored.
  • rules server 1091 in response to a request for the full driving restriction ruleset 1089, transmits the full driving restriction ruleset 1089 to validation server 1087.
  • validation server 1087 issues a request for the full driving restriction ruleset 1089 periodically (e.g., every day, every 15 days, every 30 days, every 3 months, every 6 months, etc.).
  • rules server 1091 automatically pushes the full driving restriction ruleset 1089 to validation server 1087.
  • validation server 1087 in response to receiving full driving restriction ruleset 1089, validates full driving restriction ruleset 1089 and generates a signed simplified ruleset 1085 (e.g., such as via method 1090 described above with respect to Fig.10N).
  • the signed simplified ruleset 1085 is transmitted to navigation server 1083.
  • navigation server 1083 stores and/or maintains the signed simplified ruleset 1085 and transmits the signed simplified ruleset 1085 (e.g., unmodified) to client electronic device 1081 (e.g., optionally in response to a request for the signed simplified ruleset 1085 from client electronic device 1081).
  • client electronic device 1081 issues a request for signed simplified ruleset 1085 periodically (e.g., every day, every 15 days, every 30 days, every 3 months, every 6 months, etc.).
  • client electronic device 1081 issues a request for signed simplified ruleset 1085 in response to a request, from a user, for suggested navigation routes.
  • client electronic device 1081 in response to a request for suggested navigation routes, client electronic device 1081 sends a request for navigation directions (e.g., navigation routes) to navigation server 1083.
  • the request for navigation directions sent to the navigation server 1083 includes the anonymized license plate (e.g., that was generated via method 1060 described above with respect to Figs.10L-10M).
  • navigation server 1083 generates one or more navigation routes using the received license plate (e.g., anonymized license plate).
  • navigation server 1083 has access to the full driving restriction ruleset 1089 (e.g., navigation server 1083 receives full driving restriction ruleset 1089 from rules server 1091) and is able to determine whether the received license plate is prohibited or not prohibited from driving in a restriction region. In some embodiments, if the received license plate is prohibited from driving in the restricted region, navigation server 1083 optionally only provides navigation routes that avoid the restricted region to client electronic device 1083. In some embodiments, navigation server 1083 provides both routes that avoid the restricted region and routes that do not avoid the restricted region (optionally with an indication that the license plate provided to navigation server 1083 is prohibited from traveling along the routes that do not avoid the restricted region.
  • navigation server 1083 takes into account the time window for the restrictions in the driving restriction ruleset. For example, if respective driving restrictions only apply during business hours of business days (e.g., M-F from 8:00 AM to 5:00 PM), then navigation server 1083 provides routes that avoid the restricted region only if the request for routes is received within business hours (e.g., assuming the vehicle is prohibited).
  • the request for routes received from client electronic device 1083 indicates that time at which the vehicle is planning to travel and navigation server 1083 is able to determine whether the provided license plate is restricted during the planned travel time and provide the navigation routes accordingly.
  • Fig.10P illustrates device 500 displaying one or more suggested routes that were received from a navigation server (e.g., such as navigation server 1083).
  • a navigation server e.g., such as navigation server 1083
  • the currently selected vehicle has a license plate number of “ ⁇ B32F92”, but has generated an anonymized license plate number “ ⁇ QG62Y6”, which was provided to the navigation server to generate customized routes.
  • device 500 is displaying suggested routes 1071-1 and 1071-2.
  • suggested route 1071-1 is selected to avoid the driving restriction because the navigation server has determined that the user’s license plate is prohibited from driving in the restricted region.
  • suggested route 1071-2 is selected without regard to the driving restriction.
  • device 500 receives suggested route 1071-2 from the navigation server as part of the original request for directions (e.g., which included the anonymized license plate) or as part of a separate request for directions (e.g., which did not include any license plate information, or which included a second anonymized license plate that was selected to not be prohibited from driving in the restricted region).
  • device 500 is able to anonymize the user’s license plate, transmit the anonymized license plate to a navigation server, receive one or more navigation routes from the navigation server that avoid a restricted region (e.g., if the user is prohibited) and display the one or more navigation routes for the user to view and select.
  • Fig.11 is a flow diagram illustrating a method 1100 of anonymizing a vehicle identifier in accordance with some embodiments of the disclosure.
  • the method 1100 is optionally performed at an electronic device such as device 100, device 300, and device 500 as described above with reference to Figs.1A-1B, 2-3, 4A-4B and 5A-5H. Some operations in method 1100 are, optionally combined and/or the order of some operations is, optionally, changed.
  • the method 1100 provides ways to anonymize a vehicle identifier. The method ensures that the user’s personal information is protected and reduces the cognitive burden on a user when interacting with a user interface of the device of the disclosure, thereby creating a more efficient human-machine interface.
  • an electronic device 500 with one or more processors and memory receives (1102), via a communication device (e.g., a communication subsystem, a wired or wireless communication subsystem, such as WiFi, ethernet, NFC, etc.), a set of rules associated with a driving restriction for a geographic area, such as driving restriction rules
  • a communication device e.g., a communication subsystem, a wired or wireless communication subsystem, such as WiFi, ethernet, NFC, etc.
  • a set of rules associated with a driving restriction for a geographic area such as driving restriction rules
  • the set of rules is received from an external source (e.g., a navigation server, a rules server, etc.).
  • the set of rules are a simplified set of rules that indicate which digits of a license plate are relevant and define the sets of values for the relevant digits, optionally without defining whether vehicles with the respective set of values are or are not prohibited from driving in the restricted area (e.g., without defining the outcome or result of the sets of values).
  • the simplified set of rules can indicate that the last digit is relevant to the driving restriction (e.g., because the value of the last digit determines whether the car is prohibited or not prohibited) and that cars with an even last digit are treated differently than those whose last digits are an odd number.
  • the simplified rules indicate that the cars with the last digit being even or odd are prohibited or not prohibited (e.g., the rules define the outcome or result of the sets of values).
  • the simplified rules merely indicate that the even cars are in one group and the odd cars are in another group. Both embodiments are contemplated and can be processed by the method described herein.
  • the simplified set of rules can indicate that certain rules apply during certain time periods and don’t apply during other time periods (e.g., the rules apply Monday through Friday during business hours, but not outside of these time periods).
  • multiple rules can exist and/or the rules can be nested (e.g., the result of one rule can determine whether to apply a second rule, etc.).
  • the simplified set of rules are simplified from a full set of rules.
  • the full set of rules are distilled by a server (e.g., navigation server, rules server, etc.) into the simplified set of rules before transmitting the rules to the electronic device.
  • the rules are received in response to a request by the electronic device.
  • the rules are received when the user requests navigation routes. In some embodiments, the rules are periodically received from the server (e.g., every 30 minutes, every hour, every 12 hours, every day, every week, every month, etc.).
  • the electronic device determines (1104), such as at step 1064 in Fig.10L, using the set of rules, one or more first portions of an identifier of a vehicle that are relevant to the driving restriction (1106), such as relevant portions 1068 in Figs.10L and 10M (e.g., determining the digits that are relevant to the driving restriction), wherein the identifier of the vehicle is stored on the electronic device, and the one or more first portions of the identifier are populated with one or more first values (e.g., the vehicle’s license plate information is stored on the electronic device).
  • a relevant digit is one whose value can affect the determination of whether the respective vehicle is prohibited or not prohibited.
  • the device is able to determine from this rule that the last digit of a license plate is relevant to the driving restriction because the value of the last digit dictates whether the respective vehicle is prohibited or not prohibited from driving in a restricted region.
  • multiple digits can be determined to be relevant.
  • the vehicle’s license plate information is provided by the user.
  • the vehicle’s license plate information is automatically populated from information received from an external source, such as via the method described above with respect to method 900.
  • the electronic device determines, using the set of rules, one or more second portions of the identifier of the vehicle that are not relevant to the driving restriction (1108), such as not relevant portions 1070 in Figs.10L and 10M (e.g., determining the digits that are not relevant to the driving restriction).
  • digits that are not relevant to the driving restriction are those that do not affect the determination of whether the respective vehicle is prohibited or not prohibited. For example, if the only rule in the set of rules asks whether the last digit is even or odd, then all other digits in a vehicle’s license plate are not relevant to the driving restriction.
  • the set of rules includes a first rule that asks whether the last digit is even or odd and a second rule that asks whether the first digit is between A-M or N-Z, then the digits of the vehicle’s license plate other than the first and last digit are not relevant to the driving restriction.
  • the electronic device generates (1110) an anonymized identifier corresponding to the identifier of the vehicle, such as anonymized license plate “ ⁇ QG62Y6” in Figs.10M (e.g., based on the determination of the relevant digits and the digits that are not relevant, generate a license plate for a vehicle that is a proxy for the actual license plate with respect to the driving restriction that protects the user’s actual license plate number from being sent out from the device), wherein the anonymized identifier includes one or more third portions corresponding to the one or more first portions, and one or more fourth portions corresponding to the one or more second portions (e.g., the anonymized license plate has digits that correspond to the determined relevant portions of a license plate and digits that correspond to the determined not relevant portions of the license plate).
  • an anonymized identifier corresponding to the identifier of the vehicle, such as anonymized license plate “ ⁇ QG62Y6” in Figs.10M (e.g., based on the determination of the relevant
  • the anonymized identifier is generated every time a user requests navigation routes (and optionally is discarded after the request is completed). In some embodiments, the anonymized identifier is generated every time the device receives a set of driving restriction rules. In some embodiments, the anonymized identifier is generated every time the device receives an updated set of driving restriction rules (e.g., in accordance with a determination that the set of driving restriction rules have changed).
  • generating the anonymized identifier includes selecting, for the one or more third portions, values selected from a first set of values that correspond to the one or more first values based on the set of rules, wherein the first set of values is a subset of a set of valid values for the one or more third portions (1112), such as selecting “Q” from the set of values including A-F and O-T and “6” from the set of values including 0-2, 4-7, and 9 in step 1076 of Fig.10M (e.g., for the digits that have been determined to be relevant to the driving restriction, selecting a value from the set of values that are in the same group as the actual value of the respective license plate).
  • the device selects an odd value as a proxy for the actual value for the last digit of the user’s license plate.
  • selecting a value from the same group as the user’s actual value allows the device to ensure that the anonymized license plate is still subject to the same restrictions as the user’s actual license plate.
  • the selected value is a different value than the actual value of the respective digit of the user’s license plate.
  • the selected value is the same value as the actual value of the respective digit of the user’s license plate.
  • generating the anonymized identifier includes selecting, for the one or more fourth portions, random values from a set of valid values for the one or more fourth portions (1114), such as selecting the values “ ⁇ ” “G”, “6”, “2”, and “Y” from the set of all valid values at step 1074 in Fig.10M (e.g., for the digits that have been determined to not be relevant to the driving restriction, selecting a value from all valid license plate values (for the respective digits)).
  • selecting the value includes randomly selecting a value from all valid license plate values.
  • the set of valid values for the respective digits are received from an external source (e.g., a navigation server, a rules server, etc.).
  • the selected value is a different value than the actual value of the respective digit of the user’s license plate.
  • the selected value is the same value as the actual value of the respective digit of the user’s license plate.
  • the anonymized license plate is generated by combining the selected values into a single licensed plate.
  • the anonymized license plate has the same restricted state as the original license plate.
  • the anonymized license plate has the same restriction state as the actual license plate.
  • ensuring that the anonymized license plate has the same restriction state as the actual license plate ensures that the anonymized license plate is treated similarly as the actual license plate when requesting navigation routes from a navigation server.
  • the navigation server receives a license plate with the request for navigation routes and determines the available routes for the vehicle based on whether the license plate is prohibited or not prohibited from the restricted region
  • providing the navigation server with an anonymized license plate that is also prohibited from driving in the restricted region ensures that the navigation server provides the same or similar navigation routes as if the device had provided the vehicle’s actual license plate, without requiring the device to transmit the user’s actual license plate away from the device.
  • the electronic device transmits (1116), via the communication device, the anonymized identifier to a routing server for generating a driving route in the geographic area, wherein the identifier of the vehicle is not transmitted to a destination external to the electronic device, including the routing server, such as the request for navigation directions 1077 in Fig.10O (e.g., transmitting the anonymized license plate to a routing server that determines, based on the provided license plate, the routes that are available for the respective vehicle).
  • the anonymized identifier is transmitted with a request to provide routes from a first geographic location to a second geographic location.
  • the device after transmitting the anonymized identifier, receives, from the routing server, one or more potential driving routes from the first geographic location to the second geographic location.
  • requesting navigation routes from the routing server includes transmitting the anonymized license plate, and origin and destination location information.
  • the device in response to requesting the navigation routes, receives, from the navigation server, one or more navigation routes (optionally selected based on whether the anonymized license plate is prohibited or not prohibited from driving in the restricted region).
  • the one or more potential driving routes can be selected by the routing server to avoid the respective driving restriction if the received identifier indicates that the user’s vehicle is prohibited from driving in the restricted region.
  • the one or more driving routes received from the routing server can be displayed in a map user interface, similar to described above with respect to method 700.
  • the routing server only provides routes that are not prohibited by the driving restriction.
  • the device performs the above anonymizing method twice: once to generate routes for a restricted vehicle (e.g., an anonymized identifier that falls within one group of identifiers that results in routes that avoid the restriction), and once to generate routes for an unrestricted vehicle (e.g., an anonymized identifier that falls within the other group of identifiers that results in routes that ignore the restriction) to provide the user with the option of avoiding the restriction or ignoring the restriction, as described above with respect to method 700.
  • a restricted vehicle e.g., an anonymized identifier that falls within one group of identifiers that results in routes that avoid the restriction
  • an unrestricted vehicle e.g., an anonymized identifier that falls within the other group of identifiers that results in routes that ignore the restriction
  • the anonymized identifier is generated every time the user requests routes that are affected by a driving restriction. In some embodiments, the anonymized identifier is generated every time a new set of rules is received (e.g., the device optionally determines whether the new set of rules is different than the previous set of rules and generates a new anonymized identifier accordingly).
  • the vehicle’s original license plate number is not transmitted away from the electronic device as part of the process to determine navigation routes. In some embodiments, the vehicle’s original license plate number is never transmitted away from the electronic device as a part of any map or navigation process.
  • the above-described manner of requesting routes from a routing server for a particular vehicle provides a quick and efficient way of obtaining applicable driving routes without jeopardizing the privacy of the user of the electronic device or vehicle, which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., by protecting the user’s privacy by automatically anonymizing the user’s license plate, without requiring the user to manually anonymize the vehicle’s license plate before transmission to the routing server), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the identifier of the vehicle is a license plate number of the vehicle, such as license plate number “ ⁇ B32F92” illustrated in Fig.10L (e.g., the respective driving restriction is based on the license plate number of the vehicle). For example, if a driving restriction ruleset indicates that if a vehicle’s license plate matches certain criteria, the vehicle is prohibited from driving in a restricted region and if the vehicle’s license plate does not match the criteria, the vehicle is not prohibited from driving in the restricted region.
  • the identifier can be other types of identifiers (e.g., unique or not unique).
  • the identifier is the vehicle’s color.
  • the identifier includes a vehicle identification number (VIN).
  • the identifier includes the fuel or power type of the vehicle (e.g., gas vehicle, hybrid vehicle, plug-in hybrid vehicle, electric vehicle, etc.).
  • the above-described manner of requesting routes from a routing server for a particular vehicle provides a quick and efficient way of obtaining applicable driving routes without jeopardizing the privacy of the user of the electronic device or vehicle, which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., by protecting the user’s privacy by automatically anonymizing the user’s license plate, without requiring the user to manually anonymize the vehicle’s license plate before transmission to the routing server), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the electronic device determines that a respective portion of the one or more first portions cannot be changed, such as in step 1072 in Fig.10L (e.g., determining that the driving restriction requires that a respective digit of the license plate not be anonymized).
  • a respective digit of the license plate cannot be anonymized if the determined set of valid values for the respective digit only includes one value (e.g., the value of the respective digit of the actual license plate).
  • a respective digit e.g., the first digit
  • a respective rule that asks whether the vehicle is registered in a particular region results in a determination that the first digit of the license plate cannot be anonymized (if, for example, the first digit of the actual license plate indicates that the vehicle is indeed registered in the particular region).
  • generating the anonymized identifier further includes selecting, for a respective portion of the one or more third portions corresponding to the one or more first portions, a value of the respective portion of the one or more first portions, such as in step 1076 in Fig.10L (e.g., if the driving restriction requires that a respective digit of the license plate cannot be anonymized or masked, then the respective digit for the anonymized license plate has the same value as the original license plate).
  • the set of valid values for the first digit only includes the value “A” and thus, the resulting anonymized license plate has “A” for its first digit.
  • one or more digits of the license plate can have the same value as the original license plate.
  • the other digits of the license plate that do not result in a set of valid values of just one value are able to be anonymized as described above (e.g., which optionally results in an anonymized digit that are different value than the original license plate).
  • the above-described manner of anonymizing the identifier of the vehicle provides a quick and efficient way of obtaining applicable driving routes without jeopardizing the privacy of the user of the electronic device or vehicle (e.g., by maintaining the same restriction state as the original license plate, including maintaining the same value for respective digits of the license plate if the driving restriction requires it), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., by protecting the user’s privacy by automatically anonymizing the user’s license plate, without requiring the user to manually anonymize the vehicle’s license plate before transmission to the routing server), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the set of rules includes a first rule that defines a first set of values for a first respective portion of the identifier (e.g., a first rule defines a first set of values for a respective portion of the identifier (e.g., a respective digit of a license plate) that have a first driving restriction result) and a second set of values, different from the first set of values, for the first respective portion of the identifier, such as the first rule in driving restriction ruleset 1062 in Fig.10M that defines a first set of values that includes “3” and “8” and a second set of values that includes 0-2, 4-7, and 9 (e.g., the first rule defines a second set of values for the respective portion of the identifier (e.g., the respective digit of a license plate) that have a second driving restriction result, different from the first driving restriction result).
  • a first rule defines a first set of values for a first respective portion of the identifier (e.g., a respective digit
  • the first rule defines a first set of values that are prohibited from driving. In some embodiments, the set of rules do not indicate whether the first set of values results in a prohibition or not. In some embodiments, the set of rules indicate that the first set of values exist and are optionally treated differently than the second set of values. In some embodiments, the first rule defines a second set of values that are not prohibited from driving. In some embodiments, the set of rules do not indicate whether the second set of values results in a prohibition or not. In some embodiments, the set of rules indicate that the second set of values exist and are optionally treated differently than the first set of values.
  • determining, using the set of rules, the one or more first portions of the identifier of the vehicle that are relevant to the driving restriction includes determining that the first rule defines the first and second sets of values for the first respective portion of the identifier, such as step 1064 in Fig.10M (e.g., if the set of rules includes a rule that defines two sets of valid values (optionally indicating that the two sets of values are treated differently) for a respective digit of a license plate, then the device determines that the respective digit of the license plate is relevant to the driving restriction).
  • the value of the respective digit is informative of whether the respective license plate is prohibited or not prohibited (e.g., the respective digit dictates the result or is a factor in determining the result).
  • the above-described manner of determining relevant portions of an identifier provides a quick and efficient way of determining the relevant portions of an identifier from a set of driving restriction rules (e.g., by analyzing whether the rules create different groups of values), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient, which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • a set of driving restriction rules e.g., by analyzing whether the rules create different groups of values
  • receiving the set of rules associated with the driving restriction for a geographic area includes receiving the set of rules from a rules validation server, such as signed simplified ruleset 1085 and 1079 in Fig.10O (e.g., the set of rules is validated (e.g., by a rules validation server) to determine whether the set of rules are genuine or whether the set of rules potentially violate the privacy of the user).
  • a rules validation server such as signed simplified ruleset 1085 and 1079 in Fig.10O
  • the set of rules is validated (e.g., by a rules validation server) to determine whether the set of rules are genuine or whether the set of rules potentially violate the privacy of the user).
  • the validation server validates the set of rules
  • the validation server generates a set of rules to provide the electronic device (e.g., either by transmitting the set of rules directly to the electronic device or transmitting the set of rules to a navigation server, which then transmits the set of rules to the electronic device).
  • the set of rules generated by the validation server is a signed (e.g., certified and/or encrypted) version of the original set of rules (e.g., the set of rules from the rules server).
  • the set of rules generated by the validation server is a simplified set of rules based on the original set of rules.
  • the set of rules is generated from a full set of rules associated with the driving restriction for the geographic area, such as full driving restriction ruleset 1089 in Fig.10O (e.g., the validation server receives the full set of rules from a rules server or any suitable rules repository) and indicates the one or more portions of the identifier of the vehicle that are relevant to the driving restriction and the valid sets of values for the one or more portions of the identifier of the vehicle without indicating whether the identifier of the vehicle is or it not restricted by the driving restriction (e.g., the set of values defines the relevant portions of the license plate and the sets of values for the respective relevant portions).
  • the set of values defines the relevant portions of the license plate and the sets of values for the respective relevant portions.
  • the full set of rules defines the criteria in which a vehicle is prohibited from driving in a restricted region.
  • the full set of rules can indicate that if the last digit of a license plate is even, then the vehicle is prohibited from driving in the restricted region, and if the last digit of the license plate is odd, then the vehicle is not prohibited from driving in the restricted region.
  • the validation server determines, based on the full set of rules, the digits of the license plate that are relevant to the driving restriction and the digits of the license plate that are not relevant to the driving restriction.
  • the validation server determines a first set of values for a respective relevant digit of the license plate that are prohibited from driving in the restricted region and a second set of values for the respective relevant digit of the license plate that are not prohibited from driving in the restricted region. For example, if the full set of rules can indicate that if the last digit of a license plate is even, then the vehicle is prohibited from driving in the restricted region, and if the last digit of the license plate is odd, then the vehicle is not prohibited from driving in the restricted region, then the validation server generates a first set of values that includes even values and a second set of values that includes odd values.
  • the first set of values include the values that are prohibited from driving
  • the second set of values include the values that are not prohibited from driving.
  • the set of values include only values that are valid for the respective digit of the license plate. For example, if the last digit of a license plate can only be numbers and not letters, the sets of values only include numbers and does not include letters.
  • the validation server after determining the sets of values, the validation server generates a simplified set of rules based on the full set of rules. In some embodiments, the simplified set of rules indicates which digits of a license plate are relevant (e.g., the last digit in the example provided above), and the sets of values determined above.
  • the simplified set of rules do not indicate whether a respective set of values are of values that are prohibited or are of values that are not prohibited (e.g., the simplified rules define the groups, but not whether the groups are or are not prohibited). In some embodiments, the simplified set of rules do indicate whether a respective set of values are of values that are prohibited or are of values that are not prohibited. In some embodiments, the simplified set of rules are generated only after the validation server has determined that the full set of rules do not violate a set of privacy criteria, as will be described in further detail below. In some embodiments, the validation server digitally signs the simplified set of rules (e.g., optionally with a private key associated with the validation server) to authenticate that the simplified set of rules of rules originated from the validation server.
  • the simplified set of rules e.g., optionally with a private key associated with the validation server
  • the signed and/or encrypted simplified set of rules are then provided to the electronic device (e.g., optionally via the navigation server).
  • a simplified set of rules e.g., from a rules validation server, which validates the rules and generates the simplified set of rules from a full set of rules
  • the above-described manner of receiving a simplified set of rules provides a quick and efficient way of distilling the rules into a set that is easily consumable by an electronic device (e.g., by compiling together only the information required to anonymize a license plate), which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., by pre-compiling the simplified set of rules from the full set of rules and providing the simplified set of rules to client devices, without requiring each client device to process the full set of rules), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device
  • the rules validation server determines whether the full set of rules satisfies one or more criteria, such as step 1094 in Fig.10N (e.g., the validation server determines whether the full set of rules risks violating the privacy of a user).
  • the full set of rules indicates that every digit is relevant, then the criteria is optionally not satisfied because selecting from a small set of values for every digit potentially does not anonymize the user’s license plate enough.
  • the full set of rules results in sets of valid values for a threshold number of digits with less than threshold number of values (e.g., 60%, 75%, 80%, 90% of the digits have sets of value values with less than 2, 3, 4, etc.
  • the full set of rules satisfies the one or more criteria if there is no risk that the set of rules would violate the user’s privacy.
  • the rules validation server determines whether the full set of rules is not genuine (e.g., if the full set of rules have an incorrect format, if the full set of rules are not authentically signed by the rules repository or rules server). Thus, in some embodiments, the full set of rules satisfies the one or more criteria if there is no indication that the full set of rules are not genuine.
  • the rules validation server signs the generated set of rules to be transmitted to the electronic device, such as step 1095 in Fig.10N (e.g., the rules validation server digitally signs and/or encrypts the simplified set of rules optionally using the private key of the rules validation server), wherein the electronic device is able to decrypt the generated set of rules (e.g., the client device has access to a public key of the rules validation server and is able to decrypt the simplified set of rules using the public key of the rules validation server).
  • successfully decrypting the simplified set of rules indicates that the simplified set of rules are authentic.
  • the decryption process can include multiple communication transactions (e.g., including generation and/or transmission of a temporary session key, etc.).
  • the signed simplified set of rules is provided directly to the client electronic device.
  • the signed simplified set of rules is provided to the navigation server (which optionally then provides the signed simplified rules to the client device).
  • the rules validation server in accordance with a determination that the full set of rules does not satisfy the one or more criteria, the rules validation server forgoes signing the generated set of rules, such as step 1099 in Fig.10N (e.g., if the full set of rules do not satisfy the one or more criteria, the full set of rules are not validated and are rejected by the rules validation server).
  • the rules validation server does not generate the simplified set of rules. In some embodiments, the rules validation server discards the simplified set of rules without signing, encrypting, or otherwise transmitting the simplified set of rules to a client device. In some embodiments, performing validation of the rules and signing the validated rules ensures that the rules provided to and received by the client device are authentic and do not violate any validation criteria. This process optionally also ensures that the rules have not been maliciously altered along the way. In some embodiments, the above-described validation method is performed on a client device (e.g., additionally or alternatively to validation by the rules validation server) in response to receiving a set of rules (e.g., full set of rules or simplified set of rules).
  • a set of rules e.g., full set of rules or simplified set of rules.
  • the electronic device after transmitting the anonymized identifier to the routing server, receives, from the routing server, one or more suggested routes based on the anonymized identifier, such as suggested routes 1075 in Fig.10O (e.g., the anonymized license plate is provided to a routing server or navigation server that determines one or more navigation routes).
  • the routing or navigation server has access to the full driving restriction ruleset and determines, based on the anonymized license plate, whether the user’s vehicle is prohibited or not prohibited from driving in a restricted region.
  • the routing server optionally determines the routes that avoid the restricted region (e.g., if the anonymized license plate indicates that the user’s vehicle is prohibited) and provides those routes to the electronic device. In some embodiments, the routing server determines routes that do not avoid the restriction and provides those routes to the electronic device, optionally with an indication that the user’s vehicle may be prohibited from driving along the route. In some embodiments, the routing server optionally determines that user’s vehicle is not prohibited from driving in the restricted region (e.g., if the anonymized license plate indicates that the user’s vehicle is not prohibited) and provides, to the device, one or more routes that are selected without regard to the restricted region (e.g., is not expressly selected to avoid the restricted region).
  • the routing server optionally determines the routes that avoid the restricted region (e.g., if the anonymized license plate indicates that the user’s vehicle is prohibited) and provides those routes to the electronic device.
  • the above-described anonymization process is performed multiple times to generate a first license plate that is prohibited from driving in the restricted region to receive navigation routes that avoid the restricted region, and a second license plate that is not prohibited from driving in the restricted region to receive navigation routes that are selected without regard to the restricted region.
  • the electronic device displays both routes that avoid a restricted region and routes that do not avoid the restricted region, similar to the process described above in method 700.
  • the above-described manner of generating navigation routes provides a quick and efficient way of generating navigation routes, which simplifies the interaction between the user and the electronic device and enhances the operability of the electronic device and makes the user-device interface more efficient (e.g., by protecting the user’s privacy by automatically anonymizing the user’s license plate when requesting navigation routes, without requiring the user to manually anonymize the vehicle’s license plate before transmission to the routing server), which additionally reduces power usage and improves battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiency while reducing errors in the usage of the device.
  • the operation of the electronic device anonymizing a vehicle identifier described above with reference to method 1100 optionally has one or more of the characteristics of displaying customized navigation routes, receiving information about characteristics of respective vehicles, efficient route determinations, etc., described herein with reference to other methods described herein (e.g., methods 700, 900 and 1300). For brevity, these details are not repeated here.
  • the operations in the information processing methods described above are, optionally, implemented by running one or more functional modules in an information processing apparatus such as general purpose processors (e.g., as described with respect to Figs. 1A-1B, 3, 5A-5B) or application specific chips.
  • receiving operation 1102, determining operation 1104, generating operation 1110, and transmitting operation 1116 are, optionally, implemented by event sorter 170, event recognizer 180, and event handler 190.
  • Event monitor 171 in event sorter 170 detects a contact on touch- sensitive surface 604, and event dispatcher module 174 delivers the event information to application 136-1.
  • a respective event recognizer 180 of application 136-1 compares the event information to respective event definitions 186, and determines whether a first contact at a first location on the touch-sensitive surface corresponds to a predefined event or sub-event, such as selection of an object on a user interface.
  • event recognizer 180 activates an event handler 190 associated with the detection of the event or sub-event.
  • Event handler 190 optionally utilizes or calls data updater 176 or object updater 177 to update the application internal state 192.
  • event handler 190 accesses a respective GUI updater 178 to update what is displayed by the application.
  • GUI updater 178 it would be clear to a person having ordinary skill in the art how other processes can be implemented based on the components depicted in Figs.1A-1B.
  • Starting State of Charge- and/or Buffer-Based Routes [0482] Users interact with electronic devices in many different manners, including using electronic devices to view directions from one geographic location to another geographic location.
  • different routes from one geographic location to another geographic location may be feasible (e.g., the state of charge and/or remaining range of the vehicle remains above zero throughout the routes) depending on the initial state of charge and/or starting range of the vehicle (e.g., electric vehicle, or otherwise).
  • different routes from one geographic location to another geographic location may be feasible depending on the minimum state of charge and/or remaining range allowed (e.g., by the user) for the route from the one geographic location to the other geographic location.
  • the embodiments described below provide ways for efficiently identifying feasible routes for a vehicle based on different initial states of charge for the vehicle and/or based on the minimum desired buffer state of charge for the vehicle during the routes.
  • Figs.12A-12G illustrate exemplary ways for efficiently identifying feasible routes for a vehicle based on different initial states of charge for the vehicle and/or based on the minimum desired buffer state of charge for the vehicle during the routes in accordance with some embodiments of the disclosure.
  • the embodiments in these figures are used to illustrate the processes described below, including the processes described with reference to Fig.13.
  • Figs.12A-12G illustrate various examples of performing the processes described below with reference to Fig.13, it should be understood that these examples are not meant to be limiting, the one or more processes described below with reference to Fig.13 can be performed in ways not expressly described with reference to Figs.12A-12G.
  • Fig.12A illustrates an example graph representation 1202a of a potential route or road network from an initial location (corresponding to node or vertex S 1204a) to a final location (corresponding to node or vertex T 1204f).
  • graph 1202a is a directed graph ⁇ ⁇ ⁇ ⁇ , ⁇ where V is the set of nodes or vertices, and ⁇ : ⁇ ⁇ ⁇ is the set of edges in graph 1202a (e.g., edges 1208a-1208e connecting nodes 1204a-1204f).
  • Edges 1208 are optionally associated with corresponding edge weight functions d and c.
  • Edge weight function d for a given edge 1208 optionally corresponds to the time traveled (and/or time required to travel) by the vehicle along the segment of the route or road network corresponding to that edge 1208.
  • Edge weight function c for a given edge 1208 optionally corresponds to the energy consumed by the vehicle along the segment of the route or road network corresponding to that edge 1208.
  • a subset of the nodes 1204 of graph 1202a correspond to locations along the road network that include charging stations, which are optionally associated with charging functions.
  • those charging functions are concave charging functions cf ⁇ ⁇ 0, ⁇ that map the arrival state of charge (SoC) of the battery of the vehicle and/or the time spent charging at the corresponding charging station to the SoC of the battery after charging at the corresponding charging station.
  • SoC arrival state of charge
  • node 1204b is associated with a charging station that is associated with charging function 1206a
  • node 1204e is associated with a charging station that is associated with charging function 1206b.
  • the shortest feasible path through graph 1202a is optionally one that minimizes the total travel time—including charging time (if any) at node 1204b and charging time (if any) at node 1204e—from node 1204a to node 1204f while maintaining the battery SoC above zero at all points along the route, optionally except at nodes that are associated with charging stations/functions and/or the ending node 1204f.
  • the shortest feasible path depends on the structure of G, edge weight functions d and c and/or the starting SoC of the battery of the vehicle at node S 1204a.
  • a user may wish to determine a shortest feasible path for a given starting SoC (e.g., a user may request the shortest feasible path from a first location to a second location assuming a starting SoC at node 1204a of 10% or 20% or 30%). Additionally or alternatively, a user may wish to determine a shortest feasible path given a user- defined buffer SoC (e.g., a shortest feasible path on which the SoC of the battery does not drop below the user-defined buffer SoC—optionally except at charging stations and/or the ending node 1204f).
  • a user- defined buffer SoC e.g., a shortest feasible path on which the SoC of the battery does not drop below the user-defined buffer SoC—optionally except at charging stations and/or the ending node 1204f.
  • SCM Starting Charge Maps
  • BM Buffer Maps
  • a Starting Charge Map is optionally a function ⁇ ⁇ ⁇ ⁇ ⁇ 0, ⁇ such that evaluating SCM for a given starting SoC ⁇ ⁇ ⁇ ⁇ 0, ⁇ (where M is a predetermined (e.g., the maximum) state of charge for the battery of the vehicle) and a given starting and ending location returns the corresponding shortest feasible path between the starting location and the ending location.
  • M is a predetermined (e.g., the maximum) state of charge for the battery of the vehicle) and a given starting and ending location returns the corresponding shortest feasible path between the starting location and the ending location.
  • a Buffer Map is optionally a function ⁇ ⁇ ⁇ ⁇ 0, ⁇ such that evaluating BM for a given buffer SoC ⁇ ⁇ ⁇ 0, M ⁇ returns a shortest path on which the SoC does not drop below ⁇ —optionally except at charging stations and/or the ending node 1204f.
  • determining an SCM is analogous to the shortest feasible path problem where the starting SoC is unknown.
  • SCMs as defined herein, optionally have various use cases and/or benefits.
  • the density of an SCM can be used as an indicator of the sensitivity of feasible routes to starting SoC.
  • an SCM can be used to generate and/or recommend faster routes to users if the starting SoC is higher. For example, given an SCM, generating recommendations such as “The best path with your current SoC takes 45 minutes, but you can save 15 minutes during your trip if you spend 10 more minutes charging at your present location before starting along the route” is feasible in real time.
  • an SCM can be used to generate and/or present users with feasible paths that suit the current scenario.
  • an SCM can be used to present such alternatives to drivers.
  • routes are optionally computed on a server and subsequently transmitted and presented to users on mobile clients (e.g., device 500).
  • mobile clients e.g., device 500
  • more information about the vehicle optionally needs to be transmitted to the server as compared with Internal Combustion (IC) vehicles.
  • SCMs are computed at the server and transmitted to the client (e.g., device 500) for subsequent route display, the current SoC no longer needs to be transmitted to the routing server, which may result in better privacy for users.
  • the client device would optionally use the SCMs and the SoC information (e.g., current SoC, user-defined starting SoC, etc.) itself to generate routes for presentation to the user.
  • a Reverse Charging Function Propagation (RCFP) algorithm is used to determine SCMs.
  • RCFP optionally operates on a backward graph G', which is obtained by reversing the direction of the edges in graph G (e.g., graph 1202a).
  • Fig.12B illustrates an example backward graph 1202b corresponding to graph 1202a in Fig. 12A.
  • Backward graph 1202b optionally has the same nodes 1204 as graph 1202a in Fig.12A, but has edges 1209a-1209e, which are optionally reversed with respect to edges 1208 in Fig.12A (e.g., edge 1209a corresponds to edge 1208a, but reversed; edge 1209b corresponds to edge 1208b, but reversed; etc.).
  • RCFP optionally starts at node T 1204f with a residual SoC ⁇ ⁇ (e.g., a SoC of the battery of the vehicle upon reaching the final location on the route corresponding to node T 1204f), and propagates towards node S 1204a.
  • ⁇ ⁇ is optionally an input to the algorithm.
  • a label ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ , ⁇ ⁇ ⁇ , ⁇ , ⁇ ⁇ ... ⁇ ⁇ is optionally created and stored.
  • ⁇ ⁇ is optionally the total travel time on sub-path v...u
  • u is optionally the node associated with the last charging station encountered in RCFP
  • ⁇ ⁇ ⁇ is optionally the SoC after charging at u
  • ⁇ ⁇ ... ⁇ is optionally the consumption profile of sub- path v...u.
  • sub-path v...u at node 1204b in Fig.12B is optionally the sub-path from node 1204b to node 1204e (e.g., the node associated with the last charging station encountered in RCFP starting from node T 1204f).
  • ⁇ ⁇ ⁇ is able to be determined for a given node 1204, because RCFP is a reverse search and because the energy consumption between the given node 1204 and a target node is known, the amount of charge needed to travel from the last charging station to, for example, node T 1204f while arriving at node T 1204f with residual SoC ⁇ ⁇ is also known.
  • the consumption profile of a given path P is a function ⁇ (P ): [0, M] ⁇ [( ⁇ M, M ] ⁇ ⁇ that maps the starting SoC ⁇ s for the path to the final SoC ⁇ t for the path after traversing the path P.
  • RCFP optionally utilizes inverted charging functions
  • the inverted charging functions are optionally obtained by transforming the charging functions cf ⁇ [0, M] associated with the nodes 1204 in graph G (e.g., graph 1202a) to inverted charging functions c ⁇ associated with the corresponding nodes 1204 in backward graph G' (e.g., graph 1202b).
  • inverted charging function 1207a associated with node 1204b in Fig.12B is optionally charging function 1206a associated with node 1204b in Fig.12A, but inverted.
  • inverted charging function 1207b associated with node 1204e in Fig.12B is optionally charging function 1206b associated with node 1204e in Fig.12A, but inverted.
  • the inverted charging functions used in RCFP are piecewise linear, concave and/or monotonically decreasing.
  • the inverted charging functions used in RCFP have the range [ ⁇ max , 0], where ⁇ max is the time required by a given charging station associated with node v to charge the battery of the vehicle from 0 to M SoC. Further, in some embodiments, . [0494] Given the above, RCFP optionally includes one or more of the following steps.
  • a label l' ⁇ 0,0, ⁇ , ⁇ > is optionally created and added to a priority queue PQ (e.g., a queue or stack data structure in which each element optionally additionally has a “priority” associated with it—in a priority queue, an element with high priority is optionally served before an element with low priority), which optionally stores labels in increasing order of total travel time.
  • PQ e.g., a queue or stack data structure in which each element optionally additionally has a “priority” associated with it—in a priority queue, an element with high priority is optionally served before an element with low priority
  • This node is optionally associated with an inverted starting SoC function 1210 as shown in Fig.12C (e.g., corresponding to the SoC ⁇ t of the vehicle at the end of the trip from node 1204a to 1204f).
  • a node v that is not associated with a charging function (e.g., nodes 1204c and 1204d in Fig.12B) other than the node in graph G' corresponding to the beginning of the path (e.g., node 1204a in Fig.12B)
  • a label l' ⁇ ⁇ p , 0, ⁇ , ⁇ P > is optionally created and added to L uns ( v) , which is optionally a label set for unsettled labels.
  • L uns is implemented as a min-heap with total feasible travel time as the key.
  • RCFP reaches the first node v in the backward search that is associated with a charging function (e.g., node 1204e in Fig.12D) other than the node in graph G' corresponding to the beginning of the path (e.g., node 1204a in Fig.12D)
  • a label l' ⁇ ⁇ P , ⁇ t + c P , v , ⁇ P > is optionally created and added to L uns ( v) .
  • P is optionally the sub-path from the current node (e.g., node 1204e in Fig.12D) to node T (e.g., node 1204f in Fig. 12D), ⁇ ⁇ is optionally the total travel time over P, and ⁇ ⁇ is optionally the total energy consumption over P.
  • an inverted starting SoC function 1211 associated with node 1204e is determined based on the inverted charging function 1207b and the inverted starting SoC function 1210 from Fig.12D (e.g., having been propagated to node 1204e in time and/or energy consumption according to edge 1209e).
  • inverted starting SoC function 1211 in Fig.12D reflects the characteristics of charging function 1207b and inverted starting SoC function 1210 from Fig.12C.
  • a label l' ⁇ ⁇ t , ⁇ ′ u , u , ⁇ [u...v] > is optionally extracted from PQ.
  • u optionally corresponds to the last charging station in the search (e.g., associated with node 1204e in Fig.12E).
  • An inverted starting SoC function b' l '( ⁇ ) is optionally determined (e.g., based on the characteristics of charging function 1207a and inverted starting SoC function 1211 from Fig.12D).
  • b .
  • the inverted charging functions utilized by RCFP are piecewise linear; as such, one label is optionally created for each breakpoint B of b ' l (e.g., breakpoints based on the breakpoints in inverted charging functions 1207a or 1207b).
  • RCFP When RCFP reaches the node v in graph G' corresponding to the beginning of the path (e.g., node 1204a in Fig.12E), the search is optionally terminated and backtracked to determine a path from the node v in graph G' corresponding to the end of the path (e.g., node 1204f in Fig.12E) to the node v in graph G' corresponding to the beginning of the path (e.g., node 1204a in Fig.12E).
  • label dominance criteria define that a label l' 1 dominates a label l' 2 if and only ⁇ .
  • RCFP can continue to run until PQ is empty. Doing so would optionally provide a set of all pareto-optimal feasible paths from the starting node to the ending node, which optionally forms the SCM between the starting node and the ending node for a given residual SoC at the ending node.
  • An example algorithm for determining a SCM between a source node s and a target node t is optionally as follows: while PQ is not empty do v ⁇ PQ.
  • L set( (v) is optionally a label set for unsettled labels.
  • some embodiments of the disclosure are directed to systems and methods for generating Buffer Maps BM between a source s and target t node, which are optionally functions B M ⁇ [0, M ] such that evaluating BM for a given buffer SoC b ⁇ [0, M] returns a shortest path on which the SoC does not drop below b—optionally except at charging stations and/or source/destination nodes.
  • Buffer Maps optionally have one or more of the same benefits of Starting Charge Maps, including being used to generate and/or display alternative routes to drivers that are associated with different stranding risks (e.g., because they are associated with different buffer SoC).
  • Buffer Maps optionally differ from Starting Charge Maps in that alternate routes in Buffer Maps optionally differ on the basis of projected vehicle behavior along the route (e.g., rather than differing on the basis of starting SoC).
  • Buffer Maps are determined using Iterative Charging Function Propagation (ICFP). Every iteration optionally starts with choosing a buffer SOC value b' ⁇ [0, M]. Then, a Charging Function Propagation (CFP) algorithm is run that returns a shortest feasible path P' such that the minimum SoC of the vehicle along P' is equal to b'. A collection of such paths P' optionally constitute the set of paths in the Buffer Map from s to t.
  • ICFP Iterative Charging Function Propagation
  • an example algorithm of the disclosure for determining Buffer Maps includes two parts: a first part that that returns a shortest feasible path P' that respects the current buffer SoC value in the current iteration, and a second part that computes the increase in the buffer SoC value for each iteration.
  • an example ICFP algorithm includes one or more of the following steps.
  • the algorithm optionally starts from node s with an initial SoC of the vehicle ⁇ s and propagates towards t. For example, referring to Fig.12F, the example algorithm starts at node 1204a in graph G 1202a, and propagates towards node 1204f in Fig.12F.
  • ICFP optionally creates and/or stores labels I in L uns ( v) (e.g., similar to as previously described with reference to RCFP)—labels I will be described in more detail later.
  • L uns v
  • the breakpoints of c ⁇ u are optionally ⁇ ⁇ ⁇ ⁇ ⁇ , where ⁇ ⁇ ⁇ is a tuple ( ⁇ ′ i , SoC' i ) and SoC' i is the resultant SoC of the vehicle after charging for time ⁇ ′ i at that charging station u'.
  • c ⁇ u optionally corresponds to charging function 1206a associated with node 1204b in Fig.12F
  • breakpoints ⁇ ... , ⁇ optionally correspond to the breakpoints of charging function 1206a in Fig.12F.
  • the breakpoints of c ⁇ u are optionally ⁇ is a tuple ( ⁇ i , SoC i ) (e.g., the breakpoints of charging function 1206b associated with node 1204e in Fig.12F), and SoC i is the resultant SoC of the vehicle after charging for time ⁇ i at that charging station u.
  • the SoC after charging at a given charging station u is optionally referred to as ⁇ u .
  • the breakpoint of immediately lower than ⁇ is optionally referred to as .
  • ⁇ ⁇ optionally corresponds to the breakpoint in charging function 1206a at level 1220b.
  • ⁇ ⁇ optionally corresponds to the breakpoint in charging function 1206a at level 1220b.
  • ⁇ ⁇ ⁇ t , u s , u , ⁇ [ u...v] , ⁇ , ⁇ >, which is optionally created and added to L uns ( v)
  • ⁇ optionally represents the maximum buffer SoC to which the vehicle can be charged at charging station u without a loss in charging rate (e.g., optionally, by more than a threshold amount, such as 10%, 20%, 30%, 40%, etc.).
  • ⁇ is optionally the difference between level 1220b and 1220a.
  • a leg of a path P is a portion of P between adjacent charging station nodes, and a critical leg of a path P is a leg on which the SoC drops to or below ⁇ .
  • portion 1218 corresponding to the path from node 1204b to 1204e is optionally a leg of the path from node 1204a to 1204f, and is optionally the critical leg of the path if the SoC of the vehicle is estimated to drop to (or below) b during that leg.
  • ICFP optionally collects a complete set of non-dominated labels at target node t.
  • a label ⁇ dominates l′ if: 1) the total travel time of l is less than that of l′; 2) ⁇ ⁇ l > l'′ ⁇ ⁇ ′; and 3) ⁇ ' ⁇ l ⁇ ⁇ ′ ⁇ l′.
  • a label l dominates l′ if it represents a path that takes less time, and has a faster charging station available that can charge up to a lower maximum buffer SoC.
  • Each label in the collected labels optionally represents a feasible path where the SoC along the path does not drop below b.
  • the maximum buffer charge that can be added to the battery of the vehicle at charging station(s) adjacent to the critical leg(s) of the shortest feasible path P found in the current iteration is optionally determined. This determination can be made geometrically using an X-Y plot, such as shown in Fig.12G.
  • the X-Y plot of Fig.12G has an X axis that represents total travel time for a given path associated with a label ⁇ , and a Y axis that represents buffer SoC for a given path associated with a label ⁇ .
  • a feasible path may have multiple critical legs, the charging stations adjacent to which would optionally allow the vehicle to add buffer charge at different rates, and allow the vehicle to maintain the same charging rate to different limiting buffer SoC.
  • a limiting critical leg of a path (which is optionally the critical leg of the path that controls the characteristics of the lines plotted on the X-Y plot) is optionally one that has the fastest charging rate, and allows the vehicle to maintain the same charging rate up to the lowest buffer SoC, among all critical legs along the path.
  • a label line segment is optionally added to the X-Y plot for each label ⁇ .
  • Fig.12G illustrates an example in which the collection of labels includes three labels corresponding to different paths, one corresponding to each of label line segment 1224a, label line segment 1224b, and label line segment 1224c.
  • a given label line segment 1224 has a slope ⁇ , which optionally represents the charging rate of the limiting critical leg along the feasible path, and an X-intercept equal to the total travel time ⁇ ⁇ for the given label.
  • label line segment 1224b in Fig.12G optionally has a slope corresponding to slope 1222 in Fig.12F of the portion of charging function 1206a from 1220a up to 1220b.
  • label line segment 1224a in Fig.12G optionally has a slope corresponding to the slope of charging function 1206b.
  • the difference in slope between label line segments 1224a and 1224b in Fig.12G optionally corresponds to 1225 shown in Fig.12F (e.g., the difference in slope of the relevant portions of charging functions 1206a and 1206b).
  • the maximum ordinate of a label line segment in the X-Y plot in Fig.12G is given by ⁇ .
  • ⁇ min is optionally determined by starting with the label line segment corresponding to the label in ⁇ that corresponds to the shortest feasible path (e.g., l t ) in the current iteration (e.g., shortest total travel time at the minimum buffer SoC—for example, zero), such as label line segment 1224a in Fig.12G, and identifying intersections of that label line segment with (e.g., all) other label line segments on the X-Y plot (e.g., label line segments 1224b and 1224c in Fig.12G).
  • ⁇ min is optionally given by the buffer SoC of the intersection point that is lowest on the Y-axis in the X-Y plot.
  • ⁇ min is optionally the Y-value of intersection point 1226.
  • ⁇ ⁇ is optionally the maximum buffer SoC that can be added to the vehicle in the current iteration of ICFP (e.g., corresponding to the increase in SoC between levels 1220a and 1220b on charging function 1206a in Fig.12F).
  • the feasible path corresponding to l t e.g., corresponding to label line segment 1224a
  • the feasible path corresponding to l t is optionally added to the Buffer Map (and corresponds to the feasible path for the buffer SoC value b ' for the current iteration).
  • ICFP then optionally continues to the next iteration for which the buffer SOC value b' is optionally set to ⁇ min from the current iteration.
  • the above steps are optionally performed for each iteration, resulting in additional feasible paths being added to the Buffer Map for corresponding different buffer SoC values.
  • ICFP optionally becomes more selective and the number of feasible paths from s to t optionally decreases.
  • the iterations of ICFP optionally terminate when the value for b' is sufficiently high such that no feasible paths are identified for that iteration.
  • the collection of feasible paths that have been added to the Buffer Map optionally constitute the Buffer Map for paths between starting node s and ending node t.
  • Fig.13 is a flow diagram illustrating a method 1300 of efficiently identifying feasible routes for a vehicle based on different initial states of charge for the vehicle and/or based on the minimum desired buffer state of charge for the vehicle during the routes in accordance with some embodiments of the disclosure.
  • the method 1300 is optionally performed at a servier and/or an electronic device such as device 100, device 300, and device 500 as described above with reference to Figs.1A-1B, 2-3, 4A-4B and 5A-5H.
  • Some operations in method 1300 are, optionally combined and/or the order of some operations is, optionally, changed.
  • the method 1300 provides ways to efficiently identifying feasible routes for a vehicle based on different initial states of charge for the vehicle and/or based on the minimum desired buffer state of charge for the vehicle during the routes.
  • the method enhances privacy and reduces resources (e.g., processor, storage, etc.) needed for generating recommended routes.
  • resources e.g., processor, storage, etc.
  • increasing the efficiency of operation of a device conserves power and increases the time between battery charges.
  • the method 1300 is performed at a server (e.g., such as server 1083 in Fig.10O) in response to receiving, from a separate device (e.g., a mobile phone, a tablet computer, a smart watch, etc., such as client device 1081 in Fig.10O) information about a starting and ending location for a trip.
  • a separate device e.g., a mobile phone, a tablet computer, a smart watch, etc., such as client device 1081 in Fig.10O
  • the starting and ending locations for the trip are provided in a navigation application installed on the separate device, such as described with reference to methods 700, 900 and/or 1100.
  • the method includes determining (1302a) a required initial state of charge for an electric vehicle for a trip from a first location (e.g., the starting location for the trip provided in the navigation application) to a second location (e.g., the starting location for the trip provided in the navigation application). For example, given the first and second locations, the method provides, as an output, one or more suggested (e.g., shortest time and/or shortest distance) routes from the first location to the second location, along with associated initial states of charge needed for the electric vehicle to successfully reach the destination in each of the one or more suggested routes. In some embodiments, the method takes as inputs an initial state of charge, and outputs the shortest feasible path between the first location and the second location.
  • a required initial state of charge for an electric vehicle for a trip from a first location (e.g., the starting location for the trip provided in the navigation application) to a second location (e.g., the starting location for the trip provided in the navigation application).
  • the method provides, as an output, one
  • a given suggested route includes information about the streets, highways, turns, maneuvers, etc. to follow, in addition to information about at what charging locations to charge along the route and/or how long to charge at those charging locations.
  • a navigation application installed on the device in communication with the server also provides the server with information about battery and/or drivetrain characteristics about the electric vehicle that is used to determine estimated energy/state of charge consumption of the electric vehicle along various paths from the first location to the second location.
  • determining the required initial state of charge utilizes Starting Charge Maps, as described with reference to Figs.12.
  • the below steps are performed not to determine a required initial state of charge for a vehicle for a trip between two locations, but rather to generate and/or display different feasible paths between those two locations given (e.g., as inputs) different initial states of charge for the trip.
  • the method includes identifying (1302b) a first path from the first location to the second location (e.g., a set of roads, maneuvers (e.g., turns, interchanges, etc.), etc.
  • the first path includes one or more intermediate locations between the first location and the second location (e.g., one or more locations between segments of the first path, such as intersections, interchanges, exits from highways, charging locations that include charging stations, etc.
  • the one or more intermediate locations are defined as locations along the first path that are between two segments of the first path whose energy consumption characteristics deviate by more than a threshold amount (e.g., the amount of energy consumed per unit length in the segments have opposite signs and/or differ by more than 10%, 20%, 50%, 80%, etc.)), the first path is represented by a plurality of nodes, the first location corresponds to a first node in the plurality of nodes, the second location corresponds to a second node in the plurality of nodes, and the one or more intermediate locations correspond to one or more intermediate nodes in the plurality of nodes.
  • a threshold amount e.g., the amount of energy consumed per unit length in the segments have opposite signs and/or differ by more than 10%, 20%, 50%, 80%, etc.
  • nodes in a graph structure that includes nodes that represent the first location, the second location, and the intermediate locations, such as described with reference to Fig.12B.
  • the edges that connect the nodes in the graph structure optionally represent the various segments of the path, previously described.
  • the edges in the graph structure are optionally associated with respective travel times (e.g., corresponding to the time it takes to traverse the segment of the first path that corresponds to the edge using the electric vehicle) and/or respective energy consumption amounts (e.g., corresponding to the energy consumed from and/or added to the battery of the electric vehicle by traversing the segment of the first path that corresponds to the edge using the electric vehicle).
  • the method includes providing (1302c) a starting inverted state of charge function that corresponds to a first state of charge at the second node (e.g., such as described with reference to RCFP and/or such as starting state of charge function 1210 in Fig. 12C).
  • a starting inverted state of charge function that corresponds to a first state of charge at the second node (e.g., such as described with reference to RCFP and/or such as starting state of charge function 1210 in Fig. 12C).
  • the method is provided with or operates according to a predefined a state of charge with which the electric vehicle should end the trip (e.g., 0%, 5%, 10%, 20%, 40%, etc.).
  • the suggested routes determined by the method optionally result in an estimated state of charge of the first state of charge at the second node.
  • the starting inverted state of charge function optionally reflects the first state of charge (e.g., a constant) as a function that maps state of charge to time, where the non-inverted state of charge function would optionally instead reflect the first state of charge (e.g., a constant) as a function that maps time to state of charge.
  • the starting inverted state of charge function is simply a state of charge scalar quantity that defines the ending state of charge of the vehicle at the end of the trip.
  • the method includes propagating (1302d) the starting inverted state of charge function from the second node to a first intermediate node of the one or more intermediate nodes, wherein the first intermediate node is associated with a first charging function (e.g., such as described with reference to RCFP and/or such as shown and described with reference to Figs.12C-12D).
  • the first intermediate node corresponds to a first intermediate location with a charging station along the first path from the first location to the second location.
  • the first charging function optionally maps the starting state of charge of the battery at the first intermediate location and time spent charging at the charging station to the resulting state of charge of the battery after charging for that time, and is optionally based on characteristics of the charging station and/or the battery of the electric vehicle (e.g., defining how quickly the battery of the electric vehicle can be charged at the charging station, over time).
  • the method includes generating a first inverted state of charge function based on an inverted first charging function and the propagated starting inverted state of charge function (e.g., such as described with reference to RCFP and/or such as shown and described with reference to Figs.12D or 12E).
  • the inverted first charging function optionally maps the state of charge of the battery of the electric vehicle before charging at the charging station at the first intermediate location to the time required to obtain the resulting state of charge (e.g., the maximum state of charge) after charging.
  • the first inverted state of charge function optionally accounts for the starting state of charge defined for the second node, and maps the starting state of charge at the second node to time spent charging at the charging station associated with the first charging function.
  • One or more of the steps above and below are optionally performed in generating Starting Charge Maps as described in this disclosure.
  • the Starting Charge Maps (e.g., additionally or alternatively to suggested/determined routes) are transmitted from the server to the client device (e.g., device 1018) to facilitate route generation and/or display on the client device.
  • the client device e.g., device 10128 to facilitate route generation and/or display on the client device.
  • the inverted first charging function maps a state of charge of the electric vehicle before charging based on the first charging function to a time required to achieve a predetermined state of charge for the electric vehicle after charging based on the first charging function (e.g., such as inverted charging functions 1207a and 1207b in Fig.12B).
  • a charging function is associated with a charging station, and maps the arrival state of charge of a vehicle and the time spent charging at the charging station to the state of charge of the vehicle after charging.
  • An inverted charging function optionally inverts the mappings of the corresponding charging function, and maps the state of charge of the vehicle before charging to the time required to charge at that charging station to obtain a resultant state of charge (e.g., 100%, 90%, 80%, etc. state of charge).
  • Inverted charging functions are optionally utilized by RCFP, as described with reference to Figs.12.
  • determining the required initial state of charge for the electric vehicle for the trip from the first location to the second location further includes (and/or determining Starting Charge Maps—optionally without determining the required initial state of charge for the electric vehicle for the trip from the first location to the second location—further includes) generating a second inverted state of charge function based on an inverted second charging function and a propagated first inverted state of charge function, wherein the inverted second charging function corresponds to a second charging function associated with a second intermediate node of the one or more intermediate nodes, wherein the second intermediate node is between the first node and the first intermediate node (e.g., such as shown and described with reference to Fig.12E).
  • an inverted state of charge function is determined at node 1204b in Fig.12E.
  • the inverted state of charge function is optionally based on one or more of the characteristics of the inverted second charging function, the inverted first charging function, and/or the first inverted state of charge function (e.g., having been propagated in time and/or consumption from the first intermediate node to the second intermediate node).
  • determining the required initial state of charge for the electric vehicle for the trip from the first location to the second location further includes (and/or determining Starting Charge Maps—optionally without determining the required initial state of charge for the electric vehicle for the trip from the first location to the second location—further includes) based on the first inverted state of charge function and the second inverted state of charge function, determining a first amount of recommended charging of the electric vehicle associated with the first charging function, and a second amount of recommended charging of the electric vehicle associated with the second charging function.
  • RCFP optionally identifies how much to charge at each of the charging stations to achieve the shortest feasible path from the beginning node to the ending node. For example, RCFP determines that the vehicle should charge for 15 minutes at the first charging station, and 30 minutes at the second charging station (e.g., rather than 55 minutes at the first charging station or 60 minutes at the second charging station) based on the rates of charging at the states of charge at which RCFP estimates the vehicle will arrive at each of the charging stations—thus saving 10 minutes for the total trip.
  • determining the required initial state of charge for the electric vehicle for the trip from the first location to the second location further includes (and/or determining Starting Charge Maps—optionally without determining the required initial state of charge for the electric vehicle for the trip from the first location to the second location—further includes) determining, based on the determined first and second amounts of recommended charging, the required initial state of charge for the electric vehicle for the trip from the first location to the second location.
  • the feasible path(s) added to the Starting Charge Map (e.g., which are based on the determined first and/or second amounts of recommended charging) optionally correspond to different initial states of charge.
  • the Starting Charge Map can be used to map an initial state of charge to a shortest feasible path from the first location to the second location for that initial state of charge (e.g., because the various paths in the Starting Charge Map are associated with different initial states of charge).
  • determining the required initial state of charge for the electric vehicle for the trip from the first location to the second location further includes (and/or determining Starting Charge Maps—optionally without determining the required initial state of charge for the electric vehicle for the trip from the first location to the second location—further includes): identifying a second path, different form the first path, from the first location to the second location, wherein the second path includes one or more respective intermediate locations between the first location and the second location, the second path is represented by a respective plurality of nodes, the first location corresponds to a first respective node in the respective plurality of nodes, the second location corresponds to a second respective node in the respective plurality of nodes, and the one or more respective intermediate locations correspond to one or more respective intermediate nodes in the respective plurality of nodes (e.g., if there are multiple different paths (e.g., passing through different intermediate nodes) from the first location to the second location, RCFP is optionally performed on each of the multiple different paths in the same
  • the same steps of RCFP are optionally performed with the second path as were performed with the first path.
  • the shortest feasible path for a given starting state of charge is optionally determined for each of those paths, and the shorter of those shortest feasible paths is optionally determined to be the shortest feasible path from the first location to the second location for the given starting state of charge.
  • that shorter path is added to the Starting Charge Map associated with the first and second location and the corresponding initial state of charge, and the longer of the shortest feasible paths is not. Therefore, in some embodiments, the Starting Charge Map associated with the first and second locations includes different paths (e.g., passing through different intermediate nodes) for different starting states of charge from the first location to the second location.
  • the method includes determining a shortest path (e.g., a shortest feasible path) between the first location and the second location, wherein the shortest path maintains a state of charge of the electric vehicle above a buffer state of charge (e.g., optionally except at locations associated with charging stations and/or the second location), including, identifying a critical leg in a first candidate path between the first location and the second location (e.g., the first candidate path is optionally a path utilized in a given iteration of ICFP.
  • a shortest path e.g., a shortest feasible path
  • a leg of a path is a portion of the path between adjacent charging stations, and the critical leg is the leg on which the state of charge of the vehicles drops to or below the buffer state of charge value set in the current iteration of ICFP.
  • the candidate path defines amounts of charging (if any) at charging station(s) along the path), wherein: the candidate path includes one or more respective intermediate locations between the first location and the second location, the candidate path is represented by a respective plurality of nodes, the first location corresponds to a first respective node in the respective plurality of nodes, the second location corresponds to a second respective node in the respective plurality of nodes, and the one or more respective intermediate locations correspond to one or more respective intermediate nodes in the respective plurality of nodes (e.g., such as described with reference to graph 1202a in Fig.12F), and the critical leg is a leg on the candidate path connecting adjacent intermediate nodes of the respective intermediate nodes that are associated with respective charging functions (e.g., critical leg 1218
  • the first respective intermediate node is node 1204b in Fig. 12F
  • the second respective intermediate node is node 1204e in Fig.12F
  • the method includes representing an additional charging time at the first respective intermediate node as a function that maps total travel time for the candidate path to a respective buffer state of charge.
  • the additional charging time at the first respective intermediate node corresponds to the additional amount of buffer state of charge that can be added to the vehicle in the current iteration of ICFP; for example, the additional amount of charging time that can be added to the vehicle at the charging station corresponding to the first respective intermediate node before the rate of charging decreases (e.g., more than a threshold amount, such as 10%, 20%, 30%, 40%, etc.) at that charging station.
  • the additional charging time and additional buffer state of charge that can be added at a given charging station is represented in a plot, such as shown in Fig.12H, with each charging station being represented by a line/function in the plot (e.g., 1224a-1224c).
  • the X-Y plot in Fig.12H maps total travel time to additional buffer state of charge. It is understood that in some embodiments determining the shortest path (e.g., a shortest feasible path) between the first location and the second location, wherein the shortest path maintains the state of charge of the electric vehicle above the buffer state of charge (e.g., as part of determining Buffer Maps), is performed independently of (e.g., without the need to perform) the steps described previously relating to determining Starting Charge Maps. In some embodiments, both Buffer Maps and Starting Charge Maps are determined for a given set of starting and ending locations.
  • shortest path e.g., a shortest feasible path
  • both Buffer Maps and Starting Charge Maps are determined for a given set of starting and ending locations.
  • the candidate path is a shortest path between the first location and the second location that does not maintain the state of charge of the electric vehicle above the buffer state of charge.
  • ICFP iterations optionally start with a respective buffer state of charge of zero, which is optionally below the target buffer state of charge.
  • ICFP optionally iterates and identifies candidate paths that maintain zero buffer state of charge, a first increased buffer state of charge, a second increased buffer state of charge, etc., until candidate path(s) for at least the desired buffer state of charge is (are) identified.
  • the collection of such candidate paths is optionally referred to a Buffer Map from a source to a target destination that maps a buffer state of charge to the shortest feasible path(s) that maintain that buffer state of charge.
  • the candidate path is associated with a respective state of charge of the electric vehicle at the first respective intermediate node prior to charging based on a first respective charging function associated with the first respective intermediate node (e.g., in the current iteration of ICFP, the vehicle is determined to arrive at the first respective intermediate node with the respective state of charge.
  • the first respective intermediate node is optionally associated with a charging station represented by the first respective charging function.), and determining the shortest path between the first location and the second location (e.g., as part of determining the Buffer Map for the trip between the first location and the second location) further includes: identifying an additional amount of state of charge, above the respective state of charge, for the electric vehicle that can be added at the first respective intermediate node associated with the first respective charging function without a loss of a charging rate greater than a threshold amount (e.g., 10%, 20%, 30%, etc.). For example, in the current iteration of ICFP, how much additional charging can be performed at the leading charging station of the critical leg is determined.
  • a threshold amount e.g. 10%, 20%, 30%, etc.
  • the amount of additional charging is limited to that portion of the charging function at the leading charging station of the critical leg during which the rate of charging does no decreased by more than the threshold amount relative to the rate of charging when the vehicle first starts charging at that charging station with its arrival state of charge.
  • the amount of additional charging optionally corresponds to intersection 1226 in Fig.12H.
  • the method includes identifying a second critical leg in the first candidate path (e.g., on the next iteration of ICFP) between the first location and the second location based on a second respective buffer state of charge equal to the respective state of charge of the electric vehicle increased by the additional amount of state of charge.
  • the buffer state of charge value used is optionally equal to the buffer state of charge value used in the current iteration, increased by the additional amount of state of charge determined for the current iteration as described with reference to Fig.12H.
  • the feasible path(s) corresponding to the shortest total travel time for the current iteration of ICFP is (are) optionally added to the Buffer Map as corresponding to the buffer state of charge associated with the current iteration.
  • the above-described steps of determining Buffer Maps are optionally then performed with the updated buffer state of charge value for the next iteration.
  • this gathered data may include personal information data that uniquely identifies or can be used to identify a specific person.
  • personal information data can include demographic data, location-based data, online identifiers, telephone numbers, email addresses, home addresses, data or records relating to a user’s health or level of fitness (e.g., vital signs measurements, medication information, exercise information), date of birth, license plate numbers, or any other personal information.
  • the present disclosure recognizes that the use of such personal information data, in the present technology, can be used to the benefit of users.
  • the personal information data can be used to display the user’s current location, display the user’s favorite or recently visited locations, and/or provide suggested navigation routes.
  • personal information data enables users to have more information about the user’s or the device’s location. Further, other uses for personal information data that benefit the user are also contemplated by the present disclosure.
  • the present disclosure contemplates that those entities responsible for the collection, analysis, disclosure, transfer, storage, or other use of such personal information data will comply with well-established privacy policies and/or privacy practices. In particular, such entities would be expected to implement and consistently apply privacy practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users.
  • Such information regarding the use of personal data should be prominent and easily accessible by users, and should be updated as the collection and/or use of data changes. Personal information from users should be collected for legitimate uses only.
  • policies and practices should be adapted for the particular types of personal information data being collected and/or accessed and adapted to applicable laws and standards, including jurisdiction-specific considerations that may serve to impose a higher standard.
  • the present disclosure also contemplates embodiments in which users selectively block the use of, or access to, personal information data. That is, the present disclosure contemplates that hardware and/or software elements can be provided to prevent or block access to such personal information data.
  • the present technology can be configured to allow users to select to "opt in” or “opt out” of participation in the collection of personal information data during registration for services or anytime thereafter. In another example, users can select not to enable customized navigation routes.
  • users can select to limit the sharing of the device’s location information or entirely block the display of customized routes or license plate information.
  • the present disclosure contemplates providing notifications relating to the access or use of personal information. For instance, a user may be notified upon displaying the map application that the characteristics of their vehicle (e.g., license plate number) will be used and then reminded again before customized routes are determined and/or displayed.
  • the characteristics of their vehicle e.g., license plate number
  • personal information data should be managed and handled in a way to minimize risks of unintentional or unauthorized access or use. Risk can be minimized by limiting the collection of data and deleting data once it is no longer needed.
  • data de-identification can be used to protect a user’s privacy. De-identification may be facilitated, when appropriate, by removing identifiers, controlling the amount or specificity of data stored (e.g., collecting location data at city level rather than at an address level), controlling how data is stored (e.g., aggregating data across users), and/or other methods such as differential privacy.
  • identifiers controlling the amount or specificity of data stored (e.g., collecting location data at city level rather than at an address level), controlling how data is stored (e.g., aggregating data across users), and/or other methods such as differential privacy.
  • location information can be generated and delivered to users based on non-specific information data or a bare minimum amount of identifying information, such as the determination of suggested routes based on the average driving range of vehicles similar to the user’s vehicles.
  • location information can be generated and delivered to users based on non-specific information data or a bare minimum amount of identifying information, such as the determination of suggested routes based on the average driving range of vehicles similar to the user’s vehicles.

Landscapes

  • Engineering & Computer Science (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Automation & Control Theory (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Navigation (AREA)
EP21737905.6A 2020-06-11 2021-06-11 Benutzerschnittstellen für personalisierte navigationsrouten Pending EP4143510A2 (de)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US202063038080P 2020-06-11 2020-06-11
US202063041985P 2020-06-21 2020-06-21
US17/028,322 US11846515B2 (en) 2020-06-11 2020-09-22 User interfaces for customized navigation routes
US17/028,675 US11788851B2 (en) 2020-06-11 2020-09-22 User interfaces for customized navigation routes
US17/028,638 US11740096B2 (en) 2020-06-11 2020-09-22 User interfaces for customized navigation routes
US202163193471P 2021-05-26 2021-05-26
PCT/US2021/037124 WO2021252979A2 (en) 2020-06-11 2021-06-11 User interfaces for customized navigation routes

Publications (1)

Publication Number Publication Date
EP4143510A2 true EP4143510A2 (de) 2023-03-08

Family

ID=78845954

Family Applications (1)

Application Number Title Priority Date Filing Date
EP21737905.6A Pending EP4143510A2 (de) 2020-06-11 2021-06-11 Benutzerschnittstellen für personalisierte navigationsrouten

Country Status (3)

Country Link
EP (1) EP4143510A2 (de)
CN (2) CN115803588A (de)
WO (1) WO2021252979A2 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114217710B (zh) * 2021-12-20 2023-07-21 平安付科技服务有限公司 弹框控制方法、装置、存储介质及系统
CN115220922B (zh) * 2022-02-24 2024-07-19 广州汽车集团股份有限公司 车辆应用程序运行方法、装置以及车辆

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3859005A (en) 1973-08-13 1975-01-07 Albert L Huebner Erosion reduction in wet turbines
US4826405A (en) 1985-10-15 1989-05-02 Aeroquip Corporation Fan blade fabrication system
JP2955073B2 (ja) * 1991-08-05 1999-10-04 ビステオン・テクノロジーズ，エル・エル・シー 車両用ナビゲーションシステム
IL137478A (en) 1998-01-26 2005-11-20 Westerman Wayne Method and apparatus for integrating manual input
US7218226B2 (en) 2004-03-01 2007-05-15 Apple Inc. Acceleration-based theft detection system for portable electronic devices
US7688306B2 (en) 2000-10-02 2010-03-30 Apple Inc. Methods and apparatuses for operating a portable device based on an accelerometer
US6677932B1 (en) 2001-01-28 2004-01-13 Finger Works, Inc. System and method for recognizing touch typing under limited tactile feedback conditions
US6570557B1 (en) 2001-02-10 2003-05-27 Finger Works, Inc. Multi-touch system and method for emulating modifier keys via fingertip chords
JP3758140B2 (ja) * 2001-07-09 2006-03-22 日産自動車株式会社 情報提示装置
US7657849B2 (en) 2005-12-23 2010-02-02 Apple Inc. Unlocking a device by performing gestures on an unlock image
EP2378249B1 (de) * 2010-04-15 2012-09-05 Alpine Electronics, Inc. Navigationssystem für ein Fahrzeug und Verfahren zur Routensuche
WO2012004898A1 (ja) * 2010-07-09 2012-01-12 トヨタ自動車株式会社 情報提供装置
US20130024112A1 (en) * 2011-07-18 2013-01-24 GM Global Technology Operations LLC System and method for generating recommended driving routes for an electric vehicle
KR20130033948A (ko) * 2011-09-27 2013-04-04 (주)헤르메시스 개인별 이동일정을 공유하는 방법
WO2013169849A2 (en) 2012-05-09 2013-11-14 Industries Llc Yknots Device, method, and graphical user interface for displaying user interface objects corresponding to an application
JP6158947B2 (ja) 2012-12-29 2017-07-05 アップル インコーポレイテッド タッチ入力からディスプレイ出力への関係間を遷移するためのデバイス、方法及びグラフィカルユーザインタフェース
US10197409B2 (en) * 2015-06-07 2019-02-05 Apple Inc. Frequency based transit trip characterizations
EP3104122A1 (de) * 2015-06-12 2016-12-14 Ecole Nationale de l'Aviation Civile Energieverwaltungssystem für fahrzeuge
US20180189686A1 (en) * 2016-12-30 2018-07-05 Atos Worldgrid Sl Electric vehicle charging points mobile application
US10401182B2 (en) * 2017-12-13 2019-09-03 Google Llc Systems and methods for avoiding location-dependent driving restrictions
US10845207B2 (en) * 2018-01-18 2020-11-24 Verizon Patent And Licensing Inc. Navigation based on regional navigation restrictions

Also Published As

Publication number Publication date
WO2021252979A3 (en) 2022-02-17
WO2021252979A2 (en) 2021-12-16
CN115803588A (zh) 2023-03-14
CN116124172A (zh) 2023-05-16

Similar Documents

Publication Publication Date Title
US11740096B2 (en) User interfaces for customized navigation routes
US20240094017A1 (en) User interfaces for customized navigation routes
AU2018222899B2 (en) Systems and methods for proactively identifying and surfacing relevant content on a touch-sensitive device
US11768083B2 (en) User interfaces for providing navigation directions
EP2521893B1 (de) Vorrichtung, verfahren und grafische benutzerschnittstelle zur abbildung von richtungen zwischen suchergebnissen
WO2020263375A1 (en) User interfaces for a compass application
US9459105B2 (en) Method, apparatus and computer program product for community based user involvement in map updating
DK202070634A1 (en) User interfaces for enabling an activity
US12099715B2 (en) Systems and methods for exploring a geographic region
DK180909B1 (en) Mobile key enrollment and use
EP4143510A2 (de) Benutzerschnittstellen für personalisierte navigationsrouten
WO2022098579A1 (en) Mobile key user interfaces
WO2020222988A1 (en) Utilizing context information with an electronic device
EP4153945B1 (de) Benutzerschnittstellen zur meldung von vorfällen
CN117355728A (zh) 用于定制的导航路线的用户界面
EP4028869A1 (de) Benutzerschnittstellen zum ermöglichen einer aktivität
US20240102819A1 (en) Transportation mode specific navigation user interfaces
US20240102821A1 (en) Offline maps
US20240159554A1 (en) Navigational user interfaces
WO2023239677A1 (en) Searching for stops in multistop routes
EP4327306A1 (de) Benutzerschnittstellen für einen elektronischen schlüssel
WO2024064394A1 (en) Navigation user interfaces
WO2024196564A1 (en) Contactless account information transfer user interface
AU2014202094A1 (en) Device, method, and graphical user interface for mapping directions between search results

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20221201

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)