CN116124172A - User interface for customized navigation routes - Google Patents

Abstract

The present disclosure relates generally to user interfaces for customized navigation routes. In some embodiments, the electronic device (100) displays the proposed route based on characteristics of the respective vehicle. In some embodiments, an electronic device (100) receives data of a respective vehicle from a source external to the electronic device (100). In some embodiments, an electronic device (100) anonymously processes a vehicle identifier and uses the anonymous vehicle identifier to determine a customized proposed route. In some embodiments, a starting charge map and/or a buffer map is generated and/or utilized for route generation or suggestion.

Description

User interface for customized navigation routes

The present application is a divisional application with international application number PCT/US2021/037124, international application date 2021, 6 months, 11 days, national stage date 2022, 12 months, 9 days, national application number 202180041937.1, entitled "user interface for customized navigation route".

Cross Reference to Related Applications

The present application claims priority benefits of U.S. provisional application No. 63/038,080, U.S. provisional application No. 63/041,985, U.S. patent application No. 17/028,322, U.S. patent application No. 17/028,638, U.S. patent application No. 17/028,675, U.S. provisional application No. 63/193,471, U.S. provisional application No. 17/028,675, and U.S. provisional application No. 63/193,471, U.S. provisional application No. 26, U.S. 5/2021, both of which are incorporated herein by reference in their entirety for all purposes.

Technical Field

The present disclosure relates generally to a user interface that enables a user to view a navigation route tailored to a respective vehicle.

Background

In recent years, user interaction with electronic devices has been significantly enhanced. These devices may be devices such as computers, tablets, televisions, multimedia devices, mobile devices, etc.

In some cases, the electronic device displays a map user interface. In some cases, the map user interface displays suggested directions and routes.

Disclosure of Invention

Some embodiments described in this disclosure relate to displaying suggested routes based on characteristics of respective vehicles. Some embodiments described in this disclosure relate to receiving data of a respective vehicle from an external source. Some embodiments described in this disclosure relate to anonymously processing vehicle identifiers.

Embodiments described in this disclosure provide a user with the ability to view and select a navigation route tailored to the user's vehicle. Such customization improves the overall experience of the user and interaction with the device. By customizing the views and routes based on the user's vehicle, embodiments also reduce user interaction time, which is particularly important where the input device is battery-powered.

It is well known that the use of personally identifiable information should follow privacy policies and practices that are recognized as meeting or exceeding industry or government requirements for maintaining user privacy. In particular, personally identifiable information data should be managed and processed to minimize the risk of inadvertent or unauthorized access or use, and the nature of authorized use should be specified to the user.

A full description of the embodiments is provided in the accompanying drawings and detailed description, and it is to be understood that the summary of the invention provided above is not in any way limiting the scope of the disclosure.

Drawings

For a better understanding of the various described embodiments, reference should be made to the following detailed description taken in conjunction with the accompanying drawings in which like reference numerals designate corresponding parts throughout the figures thereof.

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 processing according to some embodiments.

Fig. 2 illustrates a portable multifunction device with 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 an application menu on a portable multifunction device in accordance with some embodiments.

Fig. 4B illustrates an exemplary user interface of a multifunction device with a touch-sensitive surface separate from a display in accordance with some embodiments.

Fig. 5A illustrates a personal electronic device according to some embodiments.

Fig. 5B is a block diagram illustrating a personal electronic device, according to some embodiments.

Fig. 5C-5D illustrate exemplary components of a personal electronic device having a touch sensitive display and an intensity sensor, according to some embodiments.

Fig. 5E-5H illustrate exemplary components and user interfaces of a personal electronic device according to some embodiments.

Fig. 6A-6 FF illustrate an exemplary manner in which an electronic device displays a customized navigation route according to some embodiments of the present disclosure.

Fig. 7 is a flowchart illustrating a method of displaying a customized navigation route according to some embodiments of the present disclosure.

Fig. 8A-8 CC illustrate an exemplary manner in which an electronic device receives information regarding corresponding vehicle characteristics according to some embodiments of the present disclosure.

Fig. 9 is a flowchart illustrating a method of receiving information about a corresponding vehicle characteristic according to some embodiments of the present disclosure.

Fig. 10A-10P illustrate an exemplary manner in which a vehicle identifier is anonymously processed according to some embodiments of the present disclosure.

Fig. 11 is a flow chart illustrating a method of anonymously processing a vehicle identifier according to some embodiments of the present disclosure.

Fig. 12A-12G illustrate exemplary ways to effectively identify a viable route for a vehicle based on different initial states of charge of the vehicle and/or based on a minimum expected buffered state of charge of the vehicle during the route, according to some embodiments of the present disclosure.

Fig. 13 is a flow chart illustrating a method for efficiently identifying a viable route for a vehicle based on different initial states of charge for the vehicle and/or based on a minimum expected buffered state of charge for the vehicle during the route, according to some embodiments of the present disclosure.

Detailed Description

The following description sets forth exemplary methods, parameters, and the like. However, it should be recognized that such description is not intended as a limitation on the scope of the present disclosure, but is instead provided as a description of exemplary embodiments.

There is a need for an electronic device that provides a high-efficiency user interface and mechanism for user interaction to view customized navigation routes. In some implementations, the electronic device displays a customized navigation route for the respective vehicle based on characteristics of the respective vehicle. In some implementations, the electronic device receives information about the respective vehicle characteristics from an external source (e.g., an application, server, website, etc. associated with the respective vehicle). In some implementations, the electronic device anonymously processes the user's license plate (e.g., for requesting a customized route from a navigation server). In some implementations, a resource efficient method for generating suggested routes is employed. Such techniques may reduce the cognitive burden on users using such devices and/or protect the privacy and/or security of sensitive events while providing navigation routes tailored to the users' vehicles. Further, such techniques may reduce processor power and battery power that would otherwise be wasted on redundant user inputs.

Although the following description uses the 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 element. For example, a first touch may be named a second touch and similarly a second touch may be named a first touch without departing from the scope of the various described embodiments. Both the first touch and the second touch are touches, but they are not the same touch.

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

Depending on the context, the term "if" is optionally interpreted to mean "when..once..once.," in response to determining "or" in response to detecting ". Similarly, the phrase "if determined … …" or "if detected [ stated condition or event ]) is optionally interpreted to mean" upon determining … … "or" in response to determining … … "or" upon detecting [ stated condition or event ] "or" in response to detecting [ stated condition or event ], depending on the context.

Embodiments of electronic devices, user interfaces for such devices, and related processes for using such devices are described herein. In some embodiments, the device is a portable communication device, such as a mobile phone, that also includes other functions, such as PDA and/or music player functions. Exemplary embodiments of the portable multifunction device include, but are not limited to, those from Apple inc (Cupertino, california)

Device, iPod->

Device, and->

An apparatus. Other portable electronic devices, such as a laptop or tablet computer having a touch-sensitive surface (e.g., a touch screen display and/or a touchpad), are optionally used. It should also be appreciated that in some embodiments, the device is not a portable communication device, but rather a desktop computer having a touch-sensitive surface (e.g., a touch screen display and/or a touch pad).

In some implementations, the device 100 is a portable computing system that communicates (e.g., via wireless communication, via wired communication) with the 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. In some embodiments, the display generation component is integrated with the computer system (e.g., integrated display, touch screen 112, etc.). In some embodiments, the display generating component is separate from the computer system (e.g., an external monitor, projection system, etc.). As used herein, "displaying" content includes displaying content (e.g., video data rendered or decoded by display controller 156) by transmitting data (e.g., image data or video data) to an integrated or external display generation component via a wired or wireless connection to visually produce the content.

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

The device typically supports various applications such as one or more of the following: drawing applications, presentation applications, word processing applications, website creation applications, disk editing applications, spreadsheet applications, gaming applications, telephony applications, video conferencing applications, email applications, instant messaging applications, fitness support applications, photo management applications, digital camera applications, digital video camera applications, web browsing applications, digital music player applications, and/or digital video player applications.

The various applications executing on the device optionally use at least one generic physical user interface device, such as a touch-sensitive surface. One or more functions of the touch-sensitive surface and corresponding information displayed on the device are optionally adjusted and/or changed for different applications and/or within the respective applications. In this way, the common physical architecture of the devices (such as the touch-sensitive surface) optionally supports various applications with a user interface that is intuitive and transparent to the user.

Attention is now directed to embodiments of a portable device having a touch sensitive display. Fig. 1A is a block diagram illustrating a portable multifunction device 100 with a touch-sensitive display system 112 in accordance with some embodiments. Touch-sensitive display 112 is sometimes referred to as a "touch screen" for convenience and is sometimes referred to or referred to as a "touch-sensitive display system". Device 100 includes memory 102 (which optionally includes one or more computer-readable storage media), memory controller 122, one or more processing units (CPUs) 120, peripheral interface 118, RF circuitry 108, audio circuitry 110, speaker 111, microphone 113, input/output (I/O) subsystem 106, other input control devices 116, and external ports 124. The apparatus 100 optionally includes one or more optical sensors 164. The device 100 optionally includes one or more contact intensity sensors 165 for detecting the intensity of a contact on the device 100 (e.g., a touch-sensitive surface, such as the touch-sensitive display system 112 of the device 100). Device 100 optionally includes one or more tactile output generators 167 (e.g., generating tactile output on a touch-sensitive surface, such as touch-sensitive display system 112 of device 100 or touch pad 355 of device 300) for generating tactile output on device 100. These components optionally communicate via one or more communication buses or signal lines 103.

As used in this specification and the claims, the term "intensity" of a contact on a touch-sensitive surface refers to the force or pressure (force per unit area) of the contact on the touch-sensitive surface (e.g., finger contact), or to an alternative to the force or pressure of the contact on the touch-sensitive surface (surrogate). The intensity of the contact has a range of values that includes at least four different values and more typically includes hundreds of different values (e.g., at least 256). The intensity of the contact is optionally determined (or measured) using various methods and various sensors or combinations of sensors. For example, one or more force sensors below or adjacent to the touch-sensitive surface are optionally used to measure forces at different points on the touch-sensitive surface. In some implementations, force measurements from multiple force sensors are combined (e.g., weighted average) to determine an estimated contact force. Similarly, the pressure-sensitive tip of the stylus is optionally used to determine the pressure of the stylus on the touch-sensitive surface. Alternatively, the size of the contact area and/or its variation detected on the touch-sensitive surface, the capacitance of the touch-sensitive surface and/or its variation in the vicinity of the contact and/or the resistance of the touch-sensitive surface and/or its variation in the vicinity of the contact are optionally used as a substitute for the force or pressure of the contact on the touch-sensitive surface. In some implementations, surrogate measurements of contact force or pressure are directly used to determine whether an intensity threshold has been exceeded (e.g., the intensity threshold is described in units corresponding to surrogate measurements). In some implementations, surrogate measurements of 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 of the contact is used as an attribute of the user input, allowing the user to access additional device functions that are not otherwise accessible to the user on a smaller sized device of limited real estate for displaying affordances and/or receiving user input (e.g., via a touch-sensitive display, touch-sensitive surface, or physical/mechanical control, such as a knob or button).

As used in this specification and in the claims, the term "haptic output" refers to a physical displacement of a device relative to a previous position of the device, a physical displacement of a component of the device (e.g., a touch sensitive surface) relative to another component of the device (e.g., a housing), or a displacement of a component relative to a centroid of the device, to be detected by a user with a user's feel. For example, in the case where the device or component of the device is in contact with a touch-sensitive surface of the user (e.g., a finger, palm, or other portion of the user's hand), the haptic output generated by the physical displacement will be interpreted by the user as a haptic sensation corresponding to a perceived change in a physical characteristic of the device or component of the device. For example, movement of a touch-sensitive surface (e.g., a touch-sensitive display or touch pad) is optionally interpreted by a user as a "press click" or "click-down" of a physically actuated button. In some cases, the user will feel a tactile sensation, such as "press click" or "click down", even when the physical actuation button associated with the touch-sensitive surface that is physically pressed (e.g., displaced) by the user's movement is not moved. As another example, movement of the touch-sensitive surface may optionally be interpreted or sensed by a user as "roughness" of the touch-sensitive surface, even when the smoothness of the touch-sensitive surface is unchanged. While such interpretation of touches by a user will be limited by the user's individualized sensory perception, many sensory perceptions of touches are common to most users. Thus, when a haptic output is described as corresponding to a particular sensory perception of a user (e.g., "click down," "click up," "roughness"), unless stated otherwise, the haptic output generated corresponds to a physical displacement of the device or component thereof that would generate that sensory perception of a typical (or ordinary) user.

It should be understood that the device 100 is merely one example of a portable multifunction device, and that the 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 also optionally includes non-volatile memory, such as one or more 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.

Peripheral interface 118 may 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 the memory 102 to perform various functions of the device 100 and process data. In some embodiments, peripheral interface 118, CPU 120, and memory controller 122 are optionally implemented on a single chip, such as chip 104. In some other embodiments, they are optionally implemented on separate chips.

The RF (radio frequency) circuit 108 receives and transmits RF signals, also referred to as electromagnetic signals. RF circuitry 108 converts/converts electrical signals to/from electromagnetic signals and communicates with communication networks and other communication devices via 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 the like. RF circuitry 108 optionally communicates via wireless communication with networks such as the internet (also known as the World Wide Web (WWW)), intranets, and/or wireless networks such as cellular telephone networks, wireless Local Area Networks (LANs), and/or Metropolitan Area Networks (MANs), and other devices. The RF circuitry 108 optionally includes well-known circuitry for detecting a Near Field Communication (NFC) field, such as by a short-range communication radio. Wireless communications optionally use any of a variety of communication standards, protocols, and technologies including, but not limited to, global system for mobile communications (GSM), enhanced Data GSM Environment (EDGE), high Speed Downlink Packet Access (HSDPA), high Speed Uplink Packet Access (HSUPA), evolution, pure data (EV-DO), HSPA, hspa+, dual element HSPA (DC-HSPDA), long Term Evolution (LTE), near Field Communications (NFC), wideband code division multiple access (W-CDMA), code Division Multiple Access (CDMA), time Division Multiple Access (TDMA), bluetooth low energy (BTLE), wireless fidelity (Wi-Fi) (e.g., IEEE802.11 a, IEEE802.11 b, IEEE802.11g, IEEE802.11 n, and/or IEEE802.11 ac), voice over internet protocol (VoIP), wi-MAX, email protocols (e.g., internet Message Access Protocol (IMAP), and/or Post Office Protocol (POP)), instant messaging (e.g., extensible messaging and presence protocol (XMPP), session initiation protocol (sime), messaging and presence protocol (IMPS) for instant messaging and presence with extension, instant messaging and presence, or SMS (SMS) protocols, or any other communications protocol not yet developed on an appropriate date.

Audio circuitry 110, speaker 111, and microphone 113 provide an audio interface between the user and device 100. Audio circuitry 110 receives audio data from peripheral interface 118, converts the audio data to electrical signals, and transmits the electrical signals to speaker 111. The speaker 111 converts electrical signals into sound waves that are audible to humans. The audio circuit 110 also receives electrical signals converted from sound waves by the microphone 113. The audio circuitry 110 converts the electrical signals into audio data and transmits the audio data to the peripheral interface 118 for processing. The audio data is optionally retrieved from and/or transmitted to the memory 102 and/or the RF circuitry 108 by the peripheral interface 118. In some embodiments, the audio circuit 110 also includes a headset jack (e.g., 212 in fig. 2). The headset jack provides an interface between the audio circuit 110 and removable audio input/output peripherals such as output-only headphones or a headset having both an output (e.g., a monaural or binaural) and an input (e.g., a microphone).

I/O subsystem 106 couples input/output peripheral devices on device 100, such as touch screen 112 and other input control devices 116, to peripheral interface 118. The I/O subsystem 106 optionally includes a display controller 156, an optical sensor controller 158, an intensity sensor controller 159, a haptic feedback controller 161, and one or more input controllers 160 for other input or control devices. The one or more input controllers 160 receive electrical signals from/transmit electrical signals 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-type dials, and the like. In some alternative implementations, the input controller 160 is optionally coupled to (or not coupled to) any of the following: a keyboard, an infrared port, a USB port, and a pointing device such as a mouse. One or more buttons (e.g., 208 in fig. 2) optionally include an up/down button for volume control of speaker 111 and/or microphone 113. The one or more buttons optionally include a push button (e.g., 206 in fig. 2). In some embodiments, the electronic device is a computer system that communicates (e.g., via wireless communication, via wired communication) with one or more input devices. In some implementations, the one or more input devices include a touch-sensitive surface (e.g., a touch pad as part of a touch-sensitive display). In some embodiments, 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 gestures (e.g., hand gestures) of a user as input. In some embodiments, one or more input devices are integrated with the computer system. In some embodiments, one or more input devices are separate from the computer system.

The quick press of the push button optionally disengages the lock of the touch screen 112 or optionally begins the process of unlocking the device using gestures on the touch screen, as described in U.S. patent application Ser. No. 11/322,549 (i.e., U.S. patent No.7,657,849) entitled "Unlocking a Device by Performing Gestures on an Unlock Image," filed on even 23, 12, 2005, which is hereby incorporated by reference in its entirety. Long presses of a button (e.g., 206) optionally cause the device 100 to power on or off. The function of the one or more buttons is optionally customizable by the user. Touch screen 112 is used to implement virtual buttons or soft buttons and one or more soft keyboards.

The touch sensitive display 112 provides an input interface and an output interface between the device and the user. Display controller 156 receives electrical signals from touch screen 112 and/or transmits electrical signals to touch screen 112. Touch screen 112 displays visual output to a user. Visual output optionally includes graphics, text, icons, video, and any combination thereof (collectively, "graphics"). In some embodiments, some or all of the visual output optionally corresponds to a user interface object.

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

Touch screen 112 optionally uses LCD (liquid crystal display) technology, LPD (light emitting polymer display) technology, or LED (light emitting diode) technology, but in other embodiments other display technologies are used. Touch screen 112 and display controller 156 optionally detect contact and any movement or interruption thereof using any of a variety 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. In an exemplary embodiment, a projected mutual capacitance sensing technique is used, such as that described in the text from Apple inc (Cupertino, california)

And iPod->

Techniques used in the above.

The touch sensitive display in some implementations of touch screen 112 is optionally similar to the multi-touch sensitive touch pad described in the following U.S. patents: 6,323,846 (Westerman et al), 6,570,557 (Westerman et al) and/or 6,677,932 (Westerman et al) and/or U.S. patent publication 2002/0015024A1, each of which is hereby incorporated by reference in its entirety. However, touch screen 112 displays visual output from device 100, while touch sensitive touchpads do not provide visual output.

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

Touch screen 112 optionally has a video resolution in excess of 100 dpi. In some implementations, the touch screen has a video resolution of about 160 dpi. The user optionally uses any suitable object or appendage, such as a stylus, finger, or the like, to make contact with touch screen 112. In some embodiments, the user interface is designed to work primarily with finger-based contacts and gestures, which may not be as accurate as stylus-based input due to the large contact area of the finger on the touch screen. In some embodiments, the device translates the finger-based coarse input into a precise pointer/cursor position or command for performing the action desired by the user.

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

The apparatus 100 also includes a power system 162 for powering the various components. The 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., light Emitting Diode (LED)), and any other components associated with the generation, management, and distribution of power in the portable device.

The apparatus 100 optionally further comprises one or more optical sensors 164. FIG. 1A shows an optical sensor coupled to an optical sensor controller 158 in the I/O subsystem 106. The optical sensor 164 optionally includes a Charge Coupled Device (CCD) or a Complementary Metal Oxide Semiconductor (CMOS) phototransistor. The optical sensor 164 receives light projected through one or more lenses from the environment and converts the light into data representing an image. In conjunction with imaging module 143 (also called a camera module), optical sensor 164 optionally captures still images or video. In some embodiments, the optical sensor is located on the rear of the device 100, opposite the touch screen display 112 on the front of the device, so that the touch screen display can be used as a viewfinder for still image and/or video image acquisition. In some embodiments, the optical sensor is located on the front of the device such that the user's image is optionally acquired for video conferencing while viewing other video conference participants on the touch screen display. In some implementations, the position of the optical sensor 164 may be changed by the user (e.g., by rotating a lens and sensor in the device housing) such that a single optical sensor 164 is used with the touch screen display for both video conferencing and still image and/or video image acquisition.

The apparatus 100 optionally further comprises one or more contact intensity sensors 165. FIG. 1A shows a contact intensity sensor coupled to an intensity sensor controller 159 in the I/O subsystem 106. The contact strength sensor 165 optionally includes one or more piezoresistive strain gauges, capacitive force sensors, electrical force sensors, piezoelectric force sensors, optical force sensors, capacitive touch-sensitive surfaces, or other strength sensors (e.g., sensors for measuring force (or pressure) of a contact on a touch-sensitive surface). The contact strength sensor 165 receives contact strength information (e.g., pressure information or a surrogate for pressure information) from the environment. In some implementations, at least one contact intensity sensor is juxtaposed or adjacent to a touch-sensitive surface (e.g., touch-sensitive display system 112). In some embodiments, at least one contact intensity sensor is located on the rear of the device 100, opposite the touch screen display 112 located on the front of the device 100.

The device 100 optionally further includes one or more proximity sensors 166. Fig. 1A shows a proximity sensor 166 coupled to the peripheral interface 118. Alternatively, the proximity sensor 166 is optionally coupled to the input controller 160 in the I/O subsystem 106. The proximity sensor 166 optionally performs as described in the following U.S. patent applications: no.11/241,839, entitled "Proximity Detector In Handheld Device"; no.11/240,788, entitled "Proximity Detector In Handheld Device"; no.11/620,702, entitled "Using Ambient Light Sensor To Augment Proximity Sensor Output"; no.11/586,862, entitled "Automated Response To And Sensing Of User Activity In Portable Devices"; and No.11/638,251, entitled "Methods And Systems For Automatic Configuration Of Peripherals," which are hereby incorporated by reference in their entirety. In some embodiments, the proximity sensor is turned off and the touch screen 112 is disabled when the multifunction device is placed near the user's ear (e.g., when the user is making a telephone call).

The device 100 optionally further comprises one or more tactile output generators 167. FIG. 1A shows a haptic output generator coupled to a haptic feedback controller 161 in the I/O subsystem 106. The tactile output generator 167 optionally includes one or more electroacoustic devices such as speakers or other audio components; and/or electromechanical devices for converting energy into linear motion such as motors, solenoids, electroactive polymers, piezoelectric actuators, electrostatic actuators, or other tactile output generating means (e.g., means for converting an electrical signal into a tactile output on a device). The contact intensity sensor 165 receives haptic feedback generation instructions from the haptic feedback module 133 and generates a haptic output on the device 100 that can be perceived by a user of the device 100. In some embodiments, at least one tactile output generator is juxtaposed or adjacent to a touch-sensitive surface (e.g., touch-sensitive display system 112), and optionally generates tactile output by moving the touch-sensitive surface vertically (e.g., inward/outward of the surface of device 100) or laterally (e.g., backward and forward in the same plane as the surface of device 100). In some embodiments, at least one tactile output generator sensor is located on the rear of the device 100, opposite the touch screen display 112 located on the front of the device 100.

The device 100 optionally further includes one or more accelerometers 168. Fig. 1A shows accelerometer 168 coupled to peripheral interface 118. Alternatively, accelerometer 168 is optionally coupled to input controller 160 in I/O subsystem 106. Accelerometer 168 optionally performs as described in the following U.S. patent publications: U.S. patent publication No.20050190059, entitled "acception-based Theft Detection System for Portable Electronic Devices" and U.S. patent publication No.20060017692, entitled "Methods And Apparatuses For Operating A Portable Device Based On An Accelerometer", both of which are incorporated herein by reference in their entirety. In some implementations, information is displayed in a portrait view or a landscape view on a touch screen display based on analysis of data received from one or more accelerometers. The device 100 optionally includes a magnetometer (not shown) and a GPS (or GLONASS or other global navigation system) receiver (not shown) in addition to the accelerometer 168 for obtaining information about the position and orientation (e.g., longitudinal or lateral) of the device 100.

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

Operating system 126 (e.g., darwin, RTXC, LINUX, UNIX, OS X, iOS, WINDOWS, or embedded operating systems such as VxWorks) 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 the various hardware components and software components.

The communication module 128 facilitates communication with other devices through one or more external ports 124 and also includes various for processing data received by the RF circuitry 108 and/or the external ports 124Software components. External port 124 (e.g., universal Serial Bus (USB), firewire, etc.) is adapted to be coupled directly to other devices or indirectly via a network (e.g., the internet, wireless LAN, etc.). In some embodiments, the external port is in communication with

The 30-pin connector used on the (Apple inc. Trademark) device is the same or similar and/or compatible with a multi-pin (e.g., 30-pin) connector.

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

In some implementations, the 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 the user has "clicked" on an icon). In some implementations, at least a subset of the intensity thresholds are determined according to software parameters (e.g., the intensity thresholds are not determined by activation thresholds of particular physical actuators and may be adjusted without changing the physical hardware of the device 100). For example, without changing the touchpad or touch screen display hardware, the mouse "click" threshold of the touchpad or touch screen may be set to any of a wide range of predefined thresholds. Additionally, in some implementations, a user of the device is provided with software settings for adjusting one or more intensity thresholds in a set of intensity thresholds (e.g., by adjusting individual intensity thresholds and/or by adjusting multiple intensity thresholds at once with a system-level click on an "intensity" parameter).

The contact/motion module 130 optionally detects gesture input by the user. Different gestures on the touch-sensitive surface have different contact patterns (e.g., different movements, timings, and/or intensities of the detected contacts). Thus, gestures are optionally detected by detecting a particular contact pattern. For example, detecting a finger tap gesture includes detecting a finger press event, and then detecting a finger lift (lift off) event at the same location (or substantially the same location) as the finger press event (e.g., at the location of an icon). As another example, detecting a finger swipe gesture on the touch-sensitive surface includes detecting a finger-down event, then detecting one or more finger-dragging events, and then detecting a finger-up (lift-off) event.

Graphics module 132 includes various known software components for rendering and displaying graphics on touch screen 112 or other displays, including components for changing the visual impact (e.g., brightness, transparency, saturation, contrast, or other visual attribute) of the displayed graphics. As used herein, the term "graphic" includes any object that may be displayed to a user, including but not limited to text, web pages, icons (such as user interface objects including soft keys), digital images, video, animation, and the like.

In some embodiments, graphics module 132 stores data representing graphics to be used. Each graphic is optionally assigned a corresponding code. The graphic module 132 receives one or more codes for designating graphics to be displayed from an application program or the like, and also receives coordinate data and other graphic attribute data together if necessary, and then generates screen image data to output to the display controller 156.

Haptic feedback module 133 includes various software components for generating instructions used by haptic output generator 167 to generate haptic output at one or more locations on device 100 in response to user interaction with device 100.

Text input module 134, which is optionally a component of graphics module 132, provides a soft keyboard for entering text in various applications (e.g., contacts 137, email 140, IM 141, browser 147, and any other application requiring text input).

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

The application 136 optionally includes the following modules (or sets of instructions) or a subset or superset thereof:

● A contacts module 137 (sometimes referred to as an address book or contact list);

● A telephone module 138;

● A video conference module 139;

● An email client module 140;

● An Instant Messaging (IM) module 141;

● A fitness support module 142;

● A camera module 143 for still and/or video images;

● An image management module 144;

● A video player module;

● A music player module;

● A browser module 147;

● A calendar module 148;

● A desktop applet module 149, optionally including one or more of: weather desktop applet 149-1, stock market desktop applet 149-2, calculator desktop applet 149-3, alarm desktop applet 149-4, dictionary desktop applet 149-5, and other desktop applets obtained by the user, and user created desktop applet 149-6;

● A desktop applet creator module 150 for forming a user-created desktop applet 149-6;

● A search module 151;

● A video and music player module 152 that incorporates a video player module and a music player module;

● A note module 153;

● A map module 154; and/or

● An online video module 155.

Examples of other applications 136 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.

In conjunction with touch screen 112, display controller 156, contact/motion module 130, graphics module 132, and text input module 134, contacts module 137 is optionally used to manage an address book or contact list (e.g., in application internal state 192 of contacts module 137 stored in memory 102 or memory 370), including: adding one or more names to the address book; deleting the name from the address book; associating a telephone number, email address, physical address, or other information with the name; associating the image with the name; classifying and classifying names; providing a telephone number or email address to initiate and/or facilitate communications through telephone 138, video conferencing module 139, email 140, or IM 141; etc.

In conjunction with RF circuitry 108, audio circuitry 110, speaker 111, microphone 113, touch screen 112, display controller 156, contact/motion module 130, graphics module 132, and text input module 134, telephone module 138 is optionally used to input a sequence of characters corresponding to a telephone number, access one or more telephone numbers in contact module 137, modify the entered telephone number, dial the corresponding telephone number, conduct a conversation, and disconnect or hang up when the conversation is completed. As described above, wireless communication optionally uses any of a variety of communication standards, protocols, and technologies.

In conjunction with RF circuitry 108, audio circuitry 110, speaker 111, microphone 113, touch screen 112, display controller 156, optical sensor 164, optical sensor controller 158, contact/motion module 130, graphics module 132, text input module 134, contacts module 137, and telephony module 138, videoconferencing module 139 includes executable instructions to initiate, conduct, and terminate a videoconference between a user and one or more other participants according to user instructions.

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

In conjunction with RF circuitry 108, touch screen 112, display controller 156, contact/motion module 130, graphics module 132, and text input module 134, instant message module 141 includes executable instructions for: inputting a character sequence corresponding to an instant message, modifying previously inputted characters, transmitting a corresponding instant message (e.g., using a Short Message Service (SMS) or Multimedia Message Service (MMS) protocol for phone-based instant messages or using XMPP, SIMPLE, or IMPS for internet-based instant messages), receiving an instant message, and viewing the received instant message. In some embodiments, the transmitted and/or received instant message optionally includes graphics, photographs, audio files, video files, and/or other attachments supported in an MMS and/or Enhanced Messaging Service (EMS). As used herein, "instant message" 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).

In conjunction with RF circuitry 108, touch screen 112, display controller 156, contact/motion module 130, graphics module 132, text input module 134, GPS module 135, map module 154, and music player module, workout support module 142 includes executable instructions for creating a workout (e.g., with time, distance, and/or calorie burn targets); communicate with a fitness sensor (exercise device); receiving fitness sensor data; calibrating a sensor for monitoring fitness; selecting and playing music for exercise; and displaying, storing and transmitting the fitness data.

In conjunction with touch screen 112, display controller 156, optical sensor 164, optical sensor controller 158, contact/motion module 130, graphics module 132, and image management module 144, camera module 143 includes executable instructions for: capturing still images or videos (including video streams) and storing them in the memory 102, modifying features of still images or videos, or deleting still images or videos from the memory 102.

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

In conjunction with RF circuitry 108, touch screen 112, display controller 156, contact/motion module 130, graphics module 132, and text input module 134, browser module 147 includes executable instructions for browsing the internet according to 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.

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

In conjunction with RF circuitry 108, touch screen 112, display controller 156, contact/motion module 130, graphics module 132, text input module 134, and browser module 147, desktop applet module 149 is a mini-application (e.g., weather desktop applet 149-1, stock market desktop applet 149-2, calculator desktop applet 149-3, alarm clock desktop applet 149-4, and dictionary desktop applet 149-5) or a mini-application created by a user (e.g., user created desktop applet 149-6) that is optionally downloaded and used by a user. In some embodiments, the desktop applet includes an HTML (hypertext markup language) file, a CSS (cascading style sheet) file, and a JavaScript file. In some embodiments, the desktop applet includes an XML (extensible markup language) file and a JavaScript file (e.g., yahoo.

In conjunction with RF circuitry 108, touch screen 112, display controller 156, contact/motion module 130, graphics module 132, text input module 134, and browser module 147, a desktop applet creator module 150 is optionally used by a user to create a desktop applet (e.g., to transform a user-specified portion of a web page into a desktop applet).

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

In conjunction with touch screen 112, display controller 156, contact/motion module 130, graphics module 132, audio circuit 110, speaker 111, RF circuit 108, and browser module 147, video and music player module 152 includes executable instructions that allow a user to download and playback recorded music and other sound files stored in one or more file formats, such as MP3 or AAC files, as well as executable instructions for displaying, rendering, or otherwise playing back video (e.g., on touch screen 112 or on an external display connected via external port 124). In some embodiments, the device 100 optionally includes the functionality of an MP3 player such as an iPod (trademark of Apple inc.).

In conjunction with the touch screen 112, the display controller 156, the contact/movement module 130, the graphics module 132, and the text input module 134, the notes module 153 includes executable instructions for creating and managing notes, backlog, and the like according to user instructions.

In conjunction with RF circuitry 108, touch screen 112, display controller 156, contact/motion module 130, graphics module 132, text input module 134, GPS module 135, and browser module 147, map module 154 is optionally configured to receive, display, modify, and store maps and data associated with maps (e.g., driving directions, data related to shops and other points of interest at or near a particular location, and other location-based data) according to user instructions.

In conjunction with touch screen 112, display controller 156, contact/motion module 130, graphics module 132, audio circuit 110, speaker 111, RF circuit 108, text input module 134, email client module 140, and browser module 147, online video module 155 includes instructions for: allowing a user to access, browse, receive (e.g., by streaming and/or downloading), play back (e.g., on a touch screen or on an external display connected via external port 124), send an email with a link to a particular online video, and otherwise manage online video in one or more file formats such as h.264. In some embodiments, the instant messaging module 141 is used to send links to particular online videos instead of the email client module 140. Additional description of online video applications can be found in U.S. provisional patent application Ser. No.60/936,562, titled "Portable Multifunction Device, method, and Graphical User Interface for Playing Online Videos," filed on even date 6, 20, 2007, and U.S. patent application Ser. No.11/968,067, titled "Portable Multifunction Device, method, and Graphical User Interface for Playing Online Videos," filed on even date 12, 31, 2007, the contents of both of which are hereby incorporated by reference in their entirety.

Each of the modules and applications described above corresponds to a set of executable instructions for performing one or more of the functions described above, as well as the methods described in this patent application (e.g., the computer-implemented methods and other information processing methods described herein). These modules (e.g., sets of instructions) need not be implemented in separate software programs, procedures or modules, and thus various subsets of these modules are optionally combined or otherwise rearranged in various embodiments. For example, the video player module is optionally combined with the music player module into a single module (e.g., video and music player module 152 in fig. 1A). In some embodiments, memory 102 optionally stores a subset of the modules and data structures described above. Further, memory 102 optionally stores additional modules and data structures not described above.

In some embodiments, device 100 is a device in which the operation of a predefined set of functions on the device is performed exclusively through a touch screen and/or touch pad. By using a touch screen and/or a touch pad as the primary input control device for operating the device 100, the number of physical input control devices (e.g., push buttons, dials, etc.) on the device 100 is optionally reduced.

A predefined set of functions performed solely by the touch screen and/or touch pad optionally includes navigation between user interfaces. In some embodiments, the touchpad, when touched by a user, navigates the device 100 from any user interface displayed on the device 100 to a main menu, home menu, or root menu. In such implementations, a touch pad is used to implement a "menu button". In some other embodiments, the menu buttons are physical push buttons or other physical input control devices, rather than touch pads.

FIG. 1B is a block diagram illustrating exemplary components for event processing according to some embodiments. In some embodiments, memory 102 (FIG. 1A) or memory 370 (FIG. 3) includes event sorter 170 (e.g., in operating system 126) and corresponding applications 136-1 (e.g., any of the aforementioned applications 137-151, 155, 380-390).

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

In some implementations, the application internal state 192 includes additional information, such as one or more of the following: restoration information to be used when the application 136-1 resumes execution, user interface state information indicating that the information is being displayed or ready for display by the application 136-1, a state queue for enabling the user to return to a previous state or view of the application 136-1, and a repeat/undo queue of previous actions taken by the user.

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

In some embodiments, event monitor 171 sends requests to peripheral interface 118 at predetermined intervals. In response, the peripheral interface 118 transmits event information. In other embodiments, the peripheral interface 118 transmits event information only if there is a significant event (e.g., receiving an input above a predetermined noise threshold and/or receiving an input exceeding a predetermined duration).

In some implementations, the event classifier 170 also includes a hit view determination module 172 and/or an active event identifier determination module 173.

When the touch sensitive display 112 displays more than one view, the hit view determination module 172 provides a software process for determining where within one or more views a sub-event has occurred. The view is made up of controls and other elements that the user can see on the display.

Another aspect of the user interface associated with an application is a set of views, sometimes referred to herein as application views or user interface windows, in which information is displayed and touch-based gestures occur. The application view (of the respective application) in which the touch is detected optionally corresponds to a level of programming within the application's programming or view hierarchy. For example, the lowest horizontal view in which a touch is detected is optionally referred to as a hit view, and the set of events identified as being correctly entered is optionally determined based at least in part on the hit view of the initial touch that begins a touch-based gesture.

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

The activity event recognizer determination module 173 determines which view or views within the view hierarchy should receive a particular sequence of sub-events. In some implementations, the active event identifier determination module 173 determines that only the hit view should receive a particular sequence of sub-events. In other embodiments, the activity event recognizer determination module 173 determines that all views that include the physical location of a sub-event are actively engaged views, and thus determines that all actively engaged views should receive a particular sequence of sub-events. In other embodiments, even if the touch sub-event is completely localized to an area associated with one particular view, the higher view in the hierarchy will remain the actively engaged view.

The event dispatcher module 174 dispatches event information to an event recognizer (e.g., event recognizer 180). In embodiments that include an active event recognizer determination module 173, the event dispatcher module 174 delivers event information to the event recognizers determined by the active event recognizer determination module 173. In some embodiments, the event dispatcher module 174 stores event information in an event queue that is retrieved by the corresponding event receiver 182.

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

In some embodiments, application 136-1 includes a plurality of event handlers 190 and one or more application views 191, each of which includes instructions for processing touch events that occur within a respective view of the user interface of the application. Each application view 191 of the application 136-1 includes one or more event recognizers 180. Typically, the respective application view 191 includes a plurality of event recognizers 180. In other embodiments, one or more of the event recognizers 180 are part of a separate module that is a higher level object, such as a user interface toolkit (not shown) or application 136-1, from which to inherit methods and other properties. In some implementations, the respective event handlers 190 include one or more of the following: 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 invokes data updater 176, object updater 177, or GUI updater 178 to update the application internal state 192. Alternatively, one or more of application views 191 include one or more corresponding event handlers 190. Additionally, in some implementations, one or more of the data updater 176, the object updater 177, and the GUI updater 178 are included in a respective application view 191.

The corresponding event identifier 180 receives event information (e.g., event data 179) from the event classifier 170 and identifies events based on the event information. Event recognizer 180 includes event receiver 182 and event comparator 184. In some embodiments, event recognizer 180 further includes at least a subset of metadata 183 and event transfer 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 sub-events such as touches or touch movements. The event information also includes additional information, such as the location of the sub-event, according to the sub-event. When a sub-event relates to movement of a touch, the event information optionally also includes the rate and direction of the sub-event. In some embodiments, the event includes rotation of the device from one orientation to another orientation (e.g., from a portrait orientation to a landscape orientation, or vice versa), and the event information includes corresponding information about a current orientation of the device (also referred to as a device pose).

The event comparator 184 compares the event information with predefined event or sub-event definitions and determines an event or sub-event or determines or updates the state of the event or sub-event based on the comparison. In some embodiments, event comparator 184 includes event definition 186. Event definition 186 includes definitions of events (e.g., a predefined sequence of sub-events), such as event 1 (187-1), event 2 (187-2), and others. In some implementations, sub-events in the event (187) include, for example, touch start, touch end, touch move, touch cancel, and multi-touch. In one example, the definition of event 1 (187-1) is a double click on the displayed object. For example, a double click includes a first touch on the displayed object for a predetermined length of time (touch start), a first lift-off on the displayed object for a predetermined length of time (touch end), a second touch on the displayed object for a predetermined length of time (touch start), and a second lift-off on the displayed object for a predetermined length of time (touch end). In another example, the definition of event 2 (187-2) is a drag on the displayed object. For example, dragging includes touching (or contacting) on the displayed object for a predetermined period of time, movement of the touch on the touch-sensitive display 112, and lift-off of the touch (touch end). In some embodiments, the event also includes information for one or more associated event handlers 190.

In some implementations, the event definitions 187 include definitions of events for respective user interface objects. In some implementations, the event comparator 184 performs a hit test to determine which user interface object is associated with a sub-event. For example, in an application view that displays three user interface objects on touch-sensitive display 112, when a touch is detected on touch-sensitive display 112, event comparator 184 performs a hit test to determine which of the three user interface objects is associated with the touch (sub-event). If each displayed object is associated with a respective event handler 190, the event comparator uses the results 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 that triggered the hit test.

In some embodiments, the definition of the respective event (187) further includes a delay action that delays delivery of the event information until it has been determined that the sequence of sub-events does or does not correspond to an event type of the event recognizer.

When the respective event recognizer 180 determines that the sequence of sub-events does not match any of the events in the event definition 186, the respective event recognizer 180 enters an event impossible, event failed, or event end state after which subsequent sub-events of the touch-based gesture are ignored. In this case, the other event recognizers (if any) that remain active for the hit view continue to track and process sub-events of the ongoing touch-based gesture.

In some embodiments, the 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 the actively engaged event recognizer. In some embodiments, metadata 183 includes configurable attributes, flags, and/or lists that indicate how event recognizers interact or are able to interact with each other. In some embodiments, metadata 183 includes configurable properties, flags, and/or lists that indicate whether sub-events are delivered to different levels in a view or programmatic hierarchy.

In some embodiments, when one or more particular sub-events of an event are identified, the corresponding event recognizer 180 activates an event handler 190 associated with the event. In some implementations, the respective event identifier 180 delivers event information associated with the event to the event handler 190. The activate event handler 190 is different from sending (and deferring) sub-events to the corresponding hit view. In some embodiments, event recognizer 180 throws a marker associated with the recognized event, and event handler 190 associated with the marker obtains the marker and performs a predefined process.

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

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

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

It should be appreciated that the above discussion regarding event handling of user touches on a touch sensitive display also applies to other forms of user inputs that utilize an input device to operate the multifunction device 100, not all of which are initiated on a touch screen. For example, mouse movements and mouse button presses optionally in conjunction with single or multiple keyboard presses or holds; contact movement on the touchpad, such as tap, drag, scroll, etc.; stylus input; movement of the device; verbal instructions; detected eye movement; inputting biological characteristics; and/or any combination thereof is optionally used as input corresponding to sub-events defining the event to be identified.

Fig. 2 illustrates a portable multifunction device 100 with a touch screen 112 in accordance with some embodiments. The touch screen optionally displays one or more graphics within a User Interface (UI) 200. In this and other embodiments described below, a user can select one or more of these graphics by making a gesture on the graphics, for example, with one or more fingers 202 (not drawn to scale in the figures) or one or more styluses 203 (not drawn to scale in the figures). In some embodiments, selection of one or more graphics will occur when a user breaks contact with the one or more graphics. In some embodiments, the gesture optionally includes one or more taps, one or more swipes (left to right, right to left, up and/or down), and/or scrolling of a finger that has been in contact with the device 100 (right to left, left to right, up and/or down). In some implementations or in some cases, inadvertent contact with the graphic does not select the graphic. For example, when the gesture corresponding to the selection is a tap, a swipe gesture that swipes over an application icon optionally does not select the corresponding application.

In some embodiments, stylus 203 is an active device and includes one or more electronic circuits. For example, stylus 203 includes one or more sensors and one or more communication circuits (such as communication module 128 and/or RF circuit 108). In some embodiments, stylus 203 includes one or more processors and a power system (e.g., similar to power system 162). In some embodiments, stylus 203 includes an accelerometer (such as accelerometer 168), magnetometer, and/or gyroscope capable of determining the location, angle, position, and/or other physical characteristics of stylus 203 (e.g., such as whether the stylus is down, tilted toward or away from the device, and/or approaching or away from the device). In some embodiments, stylus 203 communicates with the electronic device (e.g., via a communication circuit, through a wireless communication protocol such as bluetooth), and transmits sensor data to the electronic device. In some implementations, stylus 203 can determine (e.g., via an accelerometer or other sensor) whether the user is holding the device. In some embodiments, stylus 203 may accept tap input (e.g., single or double tap) from a user on stylus 203 (e.g., received by an accelerometer or other sensor) and interpret the input as a command or request to perform a function or change to a different input mode.

The device 100 optionally also includes one or more physical buttons, such as a "home" or menu button 204. As previously described, menu button 204 is optionally used to navigate to any application 136 in a set of applications that are optionally executed on device 100. Alternatively, in some embodiments, the menu buttons are implemented as soft keys in a GUI displayed on touch screen 112.

In some embodiments, the device 100 includes a touch screen 112, menu buttons 204, a press button 206 for powering the device on/off and for locking the device, one or more volume adjustment buttons 208, a Subscriber Identity Module (SIM) card slot 210, a headset jack 212, and a docking/charging external port 124. Pressing button 206 is optionally used to turn on/off the device by pressing the button and holding the button in the pressed state for a predefined time interval; locking the device by depressing the button and releasing the button before the predefined time interval has elapsed; and/or unlock the device or initiate an unlocking process. In an alternative embodiment, the device 100 also accepts voice input through the microphone 113 for activating or deactivating certain functions. The device 100 also optionally includes one or more contact intensity sensors 165 for detecting the intensity of contacts on the touch screen 112, and/or one or more haptic output generators 167 for generating haptic outputs for a user of the 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. The device 300 need not be portable. In some embodiments, the device 300 is a laptop computer, a desktop computer, a tablet computer, a multimedia player device, a navigation device, an educational device (such as a child learning toy), a gaming system, or a control device (e.g., a home controller or an industrial controller). The device 300 generally includes one or more processing units (CPUs) 310, one or more network or other communication interfaces 360, memory 370, and one or more communication buses 320 for interconnecting these components. Communication bus 320 optionally includes circuitry (sometimes referred to as a chipset) that interconnects and controls communications between system components. The device 300 includes an input/output (I/O) interface 330 with a display 340, typically a touch screen display. The I/O interface 330 also optionally includes a keyboard and/or mouse (or other pointing device) 350 and a touchpad 355, a tactile output generator 357 (e.g., similar to the tactile output generator 167 described above with reference to fig. 1A), a sensor 359 (e.g., an optical sensor, an acceleration sensor, a proximity sensor, a touch sensitive sensor, and/or a contact intensity sensor (similar to the contact intensity sensor 165 described above with reference to fig. 1A)) for generating tactile output on the device 300. 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 located remotely from CPU 310. In some embodiments, memory 370 stores programs, modules, and data structures, or a subset thereof, similar to those stored in memory 102 of portable multifunction device 100 (fig. 1A). Furthermore, memory 370 optionally stores additional programs, modules, and data structures not present in memory 102 of portable multifunction device 100. For example, memory 370 of device 300 optionally stores drawing module 380, presentation module 382, word processing module 384, website creation module 386, disk editing module 388, and/or spreadsheet module 390, while memory 102 of portable multifunction device 100 (fig. 1A) optionally does not store these modules.

Each of the above elements in fig. 3 is optionally stored in one or more of the previously mentioned memory devices. Each of the above-described modules corresponds to a set of instructions for performing the above-described functions. The above-described 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. In some embodiments, memory 370 optionally stores a subset of the modules and data structures described above. Further, memory 370 optionally stores additional modules and data structures not described above.

Attention is now directed to embodiments of user interfaces optionally implemented on, for example, portable multifunction device 100.

Fig. 4A illustrates an exemplary user interface of an application menu on the portable multifunction device 100 in accordance with some embodiments. A similar user interface is optionally implemented on device 300. In some embodiments, the user interface 400 includes the following elements, or a subset or superset thereof:

● A signal strength indicator 402 for wireless communications, such as cellular signals and Wi-Fi signals;

● Time 404;

● A bluetooth indicator 405;

● A battery status indicator 406;

● A tray 408 with icons for commonly used applications such as:

an icon 416 labeled "phone" of the o-phone module 138, the icon 416 optionally including an indicator 414 of the number of missed calls or voice mails;

an icon 418 of the email client module 140 labeled "mail", the icon 418 optionally including an indicator 410 of the number of unread emails;

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

an icon 422 labeled "iPod" of the o video and music player module 152 (also referred to as iPod (trademark of Apple inc.) module 152); and

● Icons of other applications, such as:

icon 424 of oim module 141 labeled "message";

icon 426 labeled "calendar" of o calendar module 148;

icon 428 labeled "photo" of o image management module 144;

an icon 430 labeled "camera" of the o-camera module 143;

icon 432 of online video module 155 labeled "online video";

icon 434 labeled "stock market" for o stock market desktop applet 149-2;

An icon 436 labeled "map" of the o-map module 154;

icon 438 labeled "weather" for weather desktop applet 149-1;

icon 440 labeled "clock" for o-alarm desktop applet 149-4;

o icon 442 labeled "fitness support" for fitness support module 142;

icon 444 labeled "note" for the o note module 153; and

o an icon 446 labeled "set" for a set application or module that provides access to the settings of the device 100 and its various applications 136.

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

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

While some of the examples below will be given with reference to inputs on touch screen display 112 (where the touch sensitive surface and the display are combined), in some embodiments the device detects inputs on a touch sensitive surface separate from the display, as shown in fig. 4B. In some implementations, the touch-sensitive surface (e.g., 451 in fig. 4B) has a primary axis (e.g., 452 in fig. 4B) that corresponds to the primary axis (e.g., 453 in fig. 4B) on the display (e.g., 450). According to these embodiments, the device detects contact (e.g., 460 and 462 in fig. 4B) with the touch-sensitive surface 451 at a location corresponding to a respective location on the display (e.g., 460 corresponds to 468 and 462 corresponds to 470 in fig. 4B). In this way, when the touch-sensitive surface (e.g., 451 in FIG. 4B) is separated from the display (e.g., 450 in FIG. 4B) of the multifunction device, user inputs (e.g., contacts 460 and 462 and movement thereof) detected by the device on the touch-sensitive surface are used by the device to manipulate the user interface on the display. It should be appreciated that similar approaches are optionally used for other user interfaces described herein.

Additionally, while the following examples are primarily given with reference to finger inputs (e.g., finger contacts, single-finger flick gestures, finger swipe gestures), it should be understood that in some embodiments one or more of these finger inputs are replaced by input from another input device (e.g., mouse-based input or stylus input). For example, a swipe gesture is optionally replaced with a mouse click (e.g., rather than a contact), followed by movement of the cursor along the path of the swipe (e.g., rather than movement of the contact). As another example, a flick gesture is optionally replaced by a mouse click (e.g., instead of detection of contact, followed by ceasing to detect contact) when the cursor is over the position of the flick gesture. Similarly, when multiple user inputs are detected simultaneously, it should be appreciated that multiple computer mice are optionally used simultaneously, or that the mice and finger contacts are optionally used simultaneously.

Fig. 5A illustrates an exemplary personal electronic device 500. The device 500 includes a body 502. In some embodiments, device 500 may include some or all of the features described with respect to devices 100 and 300 (e.g., fig. 1A-4B). In some implementations, the device 500 has a touch sensitive display 504, hereinafter referred to as a touch screen 504. In addition to or in lieu of touch screen 504, device 500 has a display and a touch-sensitive surface. As with devices 100 and 300, in some implementations, touch screen 504 (or touch-sensitive surface) optionally includes one or more intensity sensors for detecting the intensity of an applied contact (e.g., touch). One or more intensity sensors of the touch screen 504 (or touch sensitive surface) may provide output data representative of the intensity of the touch. The user interface of the device 500 may respond to touches based on the intensity of the touches, meaning that touches of different intensities may invoke different user interface operations on the device 500.

Exemplary techniques for detecting and processing touch intensity are found, for example, in the following related patent applications: international patent application sequence No. pct/US2013/040061, filed 5/8 a 2013, entitled "Device, method, and Graphical User Interface for Displaying User Interface Objects Corresponding to an Application", issued as WIPO patent publication No. wo/2013/169849; and international patent application sequence No. pct/US2013/069483, filed 11/2013, entitled "Device, method, and Graphical User Interface for Transitioning Between Touch Input to Display Output Relationships", published as WIPO patent publication No. wo/2014/105276, each of which is hereby incorporated by reference in its entirety.

In some embodiments, the device 500 has one or more input mechanisms 506 and 508. The input mechanisms 506 and 508 (if included) may be in physical form. Examples of physical input mechanisms include push buttons and rotatable mechanisms. In some embodiments, the device 500 has one or more attachment mechanisms. Such attachment mechanisms, if included, may allow for attachment of the device 500 with, for example, a hat, glasses, earrings, necklace, shirt, jacket, bracelet, watchband, bracelet, pants, leash, shoe, purse, backpack, or the like. These attachment mechanisms allow the user to wear the device 500.

Fig. 5B depicts an exemplary personal electronic device 500. In some embodiments, the apparatus 500 may include some or all of the components described with reference to fig. 1A, 1B, and 3. The device 500 has a bus 512 that operatively couples an I/O section 514 with one or more computer processors 516 and memory 518. The I/O portion 514 may be connected to a display 504, which may have a touch sensitive component 522 and optionally an intensity sensor 524 (e.g., a contact intensity sensor). In addition, the I/O portion 514 may be connected to a communication unit 530 for receiving application and operating system data using Wi-Fi, bluetooth, near Field Communication (NFC), cellular, and/or other wireless communication technologies. The device 500 may include input mechanisms 506 and/or 508. For example, the input mechanism 506 is optionally a rotatable input device or a depressible input device and a rotatable input device. In some examples, the input mechanism 508 is optionally a button.

In some examples, the input mechanism 508 is optionally a microphone. Personal electronic device 500 optionally includes various sensors, such as a GPS sensor 532, an accelerometer 534, an orientation sensor 540 (e.g., compass), a gyroscope 536, a motion sensor 538, and/or combinations thereof, all of which are operatively connected to I/O section 514.

The memory 518 of the personal electronic device 500 may include one or more non-transitory computer-readable storage media for storing computer-executable instructions that, when executed by the one or more computer processors 516, may, for example, cause the computer processors to perform the techniques described below, including processes 700, 900, 1100, and 1300 (fig. 7, 9, 11, and 13). A computer-readable storage medium may be any medium that can tangibly contain or store computer-executable instructions for use by or in connection with an instruction execution system, apparatus, and device. In some examples, the storage medium is a transitory computer-readable storage medium. In some examples, the storage medium is a non-transitory computer-readable storage medium. The non-transitory computer readable storage medium may include, but is not limited to, magnetic storage devices, optical storage devices, and/or semiconductor storage devices. Examples of such storage devices include magnetic disks, optical disks based on CD, DVD, or blu-ray technology, and persistent solid state memories such as flash memory, solid state drives, etc. The personal electronic device 500 is not limited to the components and configuration of fig. 5B, but may include other components or additional components in a variety of configurations.

Furthermore, in a method described herein in which one or more steps are dependent on one or more conditions having been met, it should be understood that the method may be repeated in multiple iterations such that during the iteration, all conditions that determine steps in the method have been met in different iterations of the method. For example, if a method requires performing a first step (if a condition is met) and performing a second step (if a condition is not met), one of ordinary skill will know that the stated steps are repeated until both the condition and the condition are not met (not sequentially). Thus, a method described as having one or more steps depending on one or more conditions having been met may be rewritten as a method that repeats until each of the conditions described in the method have been met. However, this does not require the system or computer-readable medium to claim that the system or computer-readable medium contains instructions for performing the contingent operation based on the satisfaction of the corresponding condition or conditions, and thus is able to determine whether the contingent situation has been met without explicitly repeating the steps of the method until all conditions to decide on steps in the method have been met. It will also be appreciated by those of ordinary skill in the art that, similar to a method with optional steps, a system or computer readable storage medium may repeat the steps of the method as many times as necessary to ensure that all optional steps have been performed.

As used herein, the term "affordance" refers to a user-interactive graphical user interface object that is optionally displayed on a display screen of device 100, 300, and/or 500 (fig. 1A, 3, and 5A-5B). For example, an image (e.g., an icon), a button, and text (e.g., a hyperlink) optionally each constitute an affordance.

As used herein, the term "focus selector" refers to an input element for indicating the current portion of a user interface with which a user is interacting. In some implementations that include a cursor or other position marker, the cursor acts as a "focus selector" such that when the cursor detects an input (e.g., presses an input) on a touch-sensitive surface (e.g., touch pad 355 in fig. 3 or touch-sensitive surface 451 in fig. 4B) above a particular user interface element (e.g., a button, window, slider, or other user interface element), the particular user interface element is adjusted according to the detected input. In some implementations including a touch screen display (e.g., touch sensitive display system 112 in fig. 1A or touch screen 112 in fig. 4A) that enables direct interaction with user interface elements on the touch screen display, the contact detected on the touch screen acts as a "focus selector" such that when an input (e.g., a press input by a contact) is detected on the touch screen display at the 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. In some implementations, the focus is moved from one area of the user interface to another area of the user interface without a corresponding movement of the cursor or movement of contact on the touch screen display (e.g., by moving the focus from one button to another using a tab key or arrow key); in these implementations, the focus selector moves in accordance with movement of the focus between different areas of the user interface. Regardless of the particular form that the focus selector takes, the focus selector is typically controlled by the user in order to deliver a user interface element (or contact on the touch screen display) that is interactive with the user of the user interface (e.g., by indicating to the device the element with which the user of the user interface desires to interact). For example, upon detection of a press input on a touch-sensitive surface (e.g., a touchpad or touch screen), the position of a focus selector (e.g., a cursor, contact, or selection box) over a respective button will indicate that the user desires to activate the respective button (rather than other user interface elements shown on the device display).

As used in the specification and claims, the term "characteristic intensity" of a contact refers to the characteristic of a contact based on one or more intensities of the contact. In some embodiments, the characteristic intensity is based on a plurality of intensity samples. The characteristic intensity is optionally based on a predefined number of intensity samples or a set of intensity samples acquired during a predetermined period of time (e.g., 0.05 seconds, 0.1 seconds, 0.2 seconds, 0.5 seconds, 1 second, 2 seconds, 5 seconds, 10 seconds) relative to a predefined event (e.g., after detection of contact, before or after detection of lift-off of contact, before or after detection of start of movement of contact, before or after detection of end of contact, and/or before or after detection of decrease in intensity of contact). The characteristic intensity of the contact is optionally based on one or more of: maximum value of intensity of contact, average value of intensity of contact, value at first 10% of intensity of contact, half maximum value of intensity of contact, 90% maximum value of intensity of contact, etc. In some embodiments, 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). In some embodiments, the characteristic intensity is compared to a set of one or more intensity thresholds to determine whether the user has performed an operation. For example, the set of one or more intensity thresholds optionally includes a first intensity threshold and a second intensity threshold. In this example, contact of the feature strength that does not exceed the first threshold results in a first operation, contact of the feature strength that exceeds the first strength threshold but does not exceed the second strength threshold results in a second operation, and contact of the feature strength that exceeds the second threshold results in a third operation. In some implementations, a comparison between the feature strength and one or more thresholds is used to determine whether to perform one or more operations (e.g., whether to perform or forgo performing the respective operations) rather than for determining whether to perform the first or second operations.

FIG. 5C illustrates detecting a plurality of contacts 552A-552E on the touch-sensitive display screen 504 using a plurality of intensity sensors 524A-524D. FIG. 5C also includes an intensity graph showing the current intensity measurements of the intensity sensors 524A-524D relative to intensity units. In this example, the intensity measurements of intensity sensors 524A and 524D are each 9 intensity units, and the intensity measurements of intensity sensors 524B and 524C are each 7 intensity units. In some implementations, the cumulative intensity is the sum of the intensity measurements of the plurality of intensity sensors 524A-524D, which in this example is 32 intensity units. In some embodiments, each contact is assigned a corresponding intensity, i.e., a portion of the cumulative intensity. FIG. 5D illustrates the assignment of cumulative intensities to contacts 552A-552E based on their distance from the center of force 554. In this example, each of the contacts 552A, 552B, and 552E is assigned an intensity of the contact of 8 intensity units of cumulative intensity, and each of the contacts 552C and 552D is assigned an intensity of the contact of 4 intensity units of cumulative intensity. More generally, in some implementations, each contact j is assigned a respective intensity Ij according to a predefined mathematical function ij=a· (Dj/Σdi), which is a fraction of the cumulative intensity a, where Dj is the distance of the respective contact j from the force center, and Σdi is the sum of the distances of all the respective contacts (e.g., i=1 to last) from the force center. The operations described with reference to fig. 5C-5D may be performed using an electronic device similar or identical to device 100, 300, or 500. In some embodiments, the characteristic intensity of the contact is based on one or more intensities of the contact. In some embodiments, an intensity sensor is used to determine a single characteristic intensity (e.g., a single characteristic intensity of a single contact). It should be noted that the intensity map is not part of the displayed user interface, but is included in fig. 5C-5D to assist the reader.

In some implementations, a portion of the gesture is identified for determining a feature strength. For example, the touch-sensitive surface optionally receives a continuous swipe contact that transitions from a starting position and to an ending position where the contact intensity increases. In this example, the characteristic intensity of the contact at the end position is optionally based on only a portion of the continuous swipe contact, rather than the entire swipe contact (e.g., only the portion of the swipe contact at the end position). In some embodiments, a smoothing algorithm is optionally applied to the intensity of the swipe contact before determining the characteristic intensity of the contact. For example, the smoothing algorithm optionally includes one or more of the following: an unweighted moving average smoothing algorithm, a triangular smoothing algorithm, a median filter smoothing algorithm, and/or an exponential smoothing algorithm. In some cases, these smoothing algorithms eliminate narrow spikes or depressions in the intensity of the swipe contact for the purpose of determining the characteristic intensity.

The intensity of the 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. In some embodiments, the tap strength threshold corresponds to a strength of: at this intensity the device will perform the operations normally associated with clicking a button of a physical mouse or touch pad. In some embodiments, the deep compression intensity threshold corresponds to an intensity of: at this intensity the device will perform an operation that is different from the operation normally associated with clicking a physical mouse or a button of a touch pad. In some implementations, when a contact is detected with a characteristic intensity below a light press intensity threshold (e.g., and above a nominal contact detection intensity threshold, a contact below the nominal contact detection intensity threshold is no longer detected), the device will move the focus selector according to movement of the contact over the touch-sensitive surface without performing an operation associated with the light press intensity threshold or the deep press intensity threshold. Generally, unless otherwise stated, these intensity thresholds are consistent across different sets of user interface drawings.

The increase in contact characteristic intensity 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. The increase in contact characteristic intensity 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. The increase in the contact characteristic intensity 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 a contact on the touch surface. The decrease in the contact characteristic intensity from an intensity above the contact detection intensity threshold to an intensity below the contact detection intensity threshold is sometimes referred to as detecting a lift-off of contact from the touch surface. In some embodiments, the contact detection intensity threshold is zero. In some embodiments, the contact detection intensity threshold is greater than zero.

In some implementations described herein, one or more operations are performed in response to detecting a gesture that includes a respective press input or in response to detecting a respective press input performed with a respective contact (or contacts), wherein a respective press input is detected based at least in part on detecting an increase in intensity of the contact (or contacts) above a press input intensity threshold. In some implementations, the respective operation is performed in response to detecting that the intensity of the respective contact increases above a press input intensity threshold (e.g., a "downstroke" of the respective press input). In some embodiments, the press input includes an increase in intensity of the respective contact above a 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 "upstroke" of the respective press input).

Fig. 5E-5H illustrate the detection of a gesture that includes a press input corresponding to an increase in intensity of 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. On the displayed user interface 570 including application icons 572A-572D displayed in predefined area 574, a gesture performed with contact 562 is detected on touch-sensitive surface 560 while cursor 576 is displayed over application icon 572B corresponding to application 2. In some implementations, a gesture is detected on the touch-sensitive display 504. The intensity sensor detects the intensity of the contact on the touch-sensitive surface 560. The device determines that the intensity of contact 562 peaks when it is above a deep compression intensity threshold (e.g., "ITD"). Contact 562 is maintained on touch-sensitive surface 560. In response to detecting the gesture, and in accordance with contact 562 in which the intensity increases above a deep press intensity threshold (e.g., "ITD") during the gesture, scaled representations 578A-578C (e.g., thumbnails) of the recently opened document for application 2 are displayed, as shown in fig. 5F-5H. In some embodiments, the intensity is a characteristic intensity of the contact compared to one or more intensity thresholds. It should be noted that the intensity map for contact 562 is not part of the displayed user interface, but is included in fig. 5E-5H to assist the reader.

In some embodiments, the display of representations 578A-578C includes animation. For example, representation 578A is initially displayed adjacent to application icon 572B, as shown in FIG. 5F. As the animation proceeds, representation 578A moves upward and representation 578B is displayed adjacent to application icon 572B, as shown in fig. 5G. Representation 578A then moves upward, 578B moves upward toward representation 578A, and representation 578C is displayed adjacent to application icon 572B, as shown in fig. 5H. Representations 578A-578C form an array over icon 572B. In some embodiments, the animation progresses according to the intensity of the contact 562, as shown in fig. 5F-5G, where representations 578A-578C appear and move upward as the intensity of the contact 562 increases toward a deep press intensity threshold (e.g., "ITD"). In some embodiments, the intensity upon which the animation progresses is based is the characteristic intensity of the contact. The operations described with reference to fig. 5E through 5H may be performed using an electronic device similar or identical to device 100, 300, or 500.

In some implementations, the device employs intensity hysteresis to avoid accidental inputs, sometimes referred to as "jitter," in which the device defines or selects a hysteresis intensity threshold that has a predefined relationship to the compression input intensity threshold (e.g., the hysteresis intensity threshold is X intensity units lower than the compression input intensity threshold, or the hysteresis intensity threshold is 75%, 90%, or some reasonable proportion of the compression input intensity threshold). Thus, in some embodiments, the press input includes an increase in the intensity of the respective contact above a press input intensity threshold and a subsequent decrease in the intensity of the contact below a hysteresis intensity threshold corresponding to the press input intensity threshold, and the respective operation is performed in response to detecting that the intensity of the respective contact subsequently decreases below the hysteresis intensity threshold (e.g., an "upstroke" of the respective press input). Similarly, in some embodiments, a press input is detected only when the device detects an increase in contact intensity 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 contact intensity to an intensity at or below the hysteresis intensity, and a corresponding operation is performed in response to detecting a press input (e.g., an increase in contact intensity or a decrease in contact intensity depending on the circumstances).

For ease of explanation, optionally, a description of operations performed in response to a press input associated with a press input intensity threshold or in response to a gesture comprising a press input is triggered in response to detecting any of the following: the contact strength increases above the compression input strength threshold, the contact strength increases from an intensity below the hysteresis strength threshold to an intensity above the compression input strength threshold, the contact strength decreases below the compression input strength threshold, and/or the contact strength decreases below the hysteresis strength threshold corresponding to the compression input strength threshold. In addition, in examples where the operation is described as being performed in response to the intensity of the detected contact decreasing below a press input intensity threshold, the operation is optionally performed in response to the intensity of the detected contact decreasing below a hysteresis intensity threshold that corresponds to and is less than the press input intensity threshold.

As used herein, an "installed application" refers to a software application that has been downloaded onto an electronic device (e.g., device 100, 300, and/or 500) and is ready to be started (e.g., turned on) on the device. In some embodiments, the downloaded application becomes an installed application using an installer that extracts program portions from the downloaded software package and integrates the extracted portions with the operating system of the computer system.

As used herein, the term "open application" or "executing application" refers to a software application having retention state information (e.g., as part of device/global internal state 157 and/or application internal state 192). The open or executing application is optionally any of the following types of applications:

● An active application currently displayed on a display screen of a device that is using the application;

● A background application (or background process) that is not currently shown but for which one or more processes are being processed by one or more processors; and

● Not running but having memory stored (volatile and non-volatile respectively)

And may be used to resume a suspended or dormant application of state information for execution of the application.

As used herein, the term "closed application" refers to a software application that does not have maintained state information (e.g., the state information of the closed application is not stored in the memory of the device). Thus, closing an application includes stopping and/or removing application processes of the application and removing state information of the application from memory of the device. Generally, when in a first application, opening a second application does not close the first application. The first application becomes a background application when the second application is displayed and the first application stops being displayed.

Attention is now directed to embodiments of a user interface ("UI") and associated processes implemented on an electronic device, such as device 100, device 300, or device 500.

User interface and associated process

Customizing navigation routes

Users interact with electronic devices in many different ways, including using electronic devices to view and find geographic locations on a map. In some embodiments, a user may request directions from one geographic location to another. The embodiments described below provide a means for displaying custom suggested routes between locations. These routes may be customized based on the characteristics of the user's vehicle. Such customization enhances user interaction with the electronic device and shortens the length of time required for the user to perform an operation. Shortening the operating time reduces the power usage of the device and extends the battery life of the battery-powered device.

Fig. 6A-6 FF illustrate an exemplary manner in which an electronic device displays a customized navigation route according to some embodiments of the present disclosure. The embodiments in these figures are used to illustrate the processes described below, including the processes described with reference to fig. 7. While fig. 6A-6 FF illustrate various examples of the manner in which an electronic device may be able to perform the processes described below with reference to fig. 7, it should be understood that these examples are not meant to be limiting and that the electronic device may be able to perform one or more of the processes described below with reference to fig. 7 in a manner that is not explicitly described with reference to fig. 6A-6 FF.

Fig. 6A illustrates an electronic device 500 displaying a user interface 600 (e.g., via a display device, via a display generation component, etc.). In some embodiments, the user interface 600 is displayed via a display generation component. In some embodiments, the display generation component is a hardware component (e.g., including electronic components) capable of receiving display data and displaying a user interface. In some embodiments, examples of display generating components 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 in communication with device 500.

In some implementations, the 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 locations, and/or request directions from one location to another). In some implementations, the map application is an application installed on the device 500.

In some implementations, the map application may present maps, routes, location metadata, and/or images (e.g., captured photographs) associated with various geographic locations, points of interest, and the like. The map application may obtain map data from a navigation server, including data defining a map, map objects, routes, points of interest, images, and the like. For example, map data may be received as map tiles that include map data for geographic areas corresponding to respective map tiles. The map data may include, among other things, data defining roads and/or segments, metadata for points of interest and other locations, three-dimensional models of buildings, infrastructure and other objects found at various locations and/or images captured at various locations. The map application may request map data (e.g., map tiles) associated with locations frequently accessed by the device 500 from a navigation server over a network (e.g., a local area network, a cellular data network, a wireless network, the internet, a wide area network, etc.). The map application may store map data in a map database. The map application may use map data stored in a map database and/or other map data received from the device 500 to provide map application features described herein (e.g., display of customized navigation routes).

In some embodiments, the navigation server may be a software server configured to obtain, generate, and/or store map data. For example, the navigation server may obtain lidar-generated point clouds for various locations included in the map data (e.g., points defining locations of the object surface near the image capture location). The navigation server may generate a three-dimensional model (e.g., a three-dimensional grid) for each of the respective locations using the respective point clouds of the respective locations. The navigation server may obtain images captured at various locations (e.g., captured locations) and use the images to add texture to the three-dimensional model, thereby generating a realistic three-dimensional image representing the corresponding locations. For example, a captured image (e.g., photograph, panoramic photograph, etc.) may be stretched over a surface of a three-dimensional model for a particular location to generate a realistic three-dimensional view of the particular location. The three-dimensional model and texture (e.g., captured images, stretched images, images applied to the three-dimensional model, etc.) may be stored in a map database on a navigation server and provided to a user device (e.g., device 500) to provide the various features and functions described herein. The navigation server may be configured to obtain, generate, and/or store other map data in the map database.

It should be appreciated that while the description of the figures below describes an embodiment in which the device 500 determines one or more suggested routes and/or determines one or more suggested stops, the determination may be performed by a navigation server or by a combination of the device 500 and the navigation server, the results of which are provided to the device 500 for display in a user interface via a display generating component of the device 500.

In fig. 6A, user interface 600 includes a representation of a map. For example, in fig. 6A, user interface 600 includes representations (e.g., textual and/or graphical representations) associated with particular geographic locations, including representations of roads, landmarks, businesses, and/or buildings, etc. In some embodiments, the user is able to search for a corresponding location or address. For example, in FIG. 6A, the user has performed a search for destination 1. In some implementations, in response to the search for destination 1, the user interface 600 includes a representation 604 at a location on the map that corresponds to the location of destination 1, as shown in fig. 6A.

In some implementations, the map application searches a map database for a location (e.g., place) that matches the search criteria (e.g., for destination 1). The map application may send a request to the navigation server to cause the navigation server to search for a location that matches the search criteria. After obtaining map data corresponding to the search criteria, the map application may present a list of places that match the search criteria, and the user may select one of these places to cause the place (e.g., address, point of interest, landmark, etc.) to be presented on the user interface 600.

In fig. 6A, the device 500 displays a user interface 606 corresponding to destination 1. In some embodiments, user interface 606 is displayed overlaid on user interface 600. In some implementations, the user interface 606 includes information associated with destination 1. In fig. 6A, user interface 606 includes text indications 608, buttons 610, and graphics 612. In some embodiments, the text indication 608 includes the name of destination 1 and/or the address of destination 1. In some implementations, the button 610 is selectable to request and/or display navigation directions to the destination 1 (e.g., from a current location of the electronic device or from a corresponding location provided by a user). In some implementations, the graphic 612 includes an image associated with destination 1 (e.g., an image of a location, an image of a view of destination 1 from a street level, etc.). In some embodiments, the user interface 606 includes a button 614 that is selectable to dismiss the user interface 606 (e.g., and optionally stop display of search results).

In fig. 6A, user input 603a is received by selecting button 610. In some embodiments, in response to user input, device 500 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. In FIG. 6B, the apparatus 500 displays the proposed route 620-1 and the proposed route 620-2. In some implementations, suggested route 620-1 is the fastest route to destination 1. In some implementations, the proposed route 620-2 is an alternative route to the proposed route 620-1. In some embodiments, the proposed route 620-1 and/or the proposed route 620-2 is selected based on different conditions such as shortest route, fastest route, avoid tolls, avoid highways, etc. In some embodiments, the proposed route is selected while taking into account current traffic conditions. In fig. 6B, because no vehicle is currently selected in the map application, the proposed route is selected without consideration of the corresponding vehicle characteristics (e.g., the mileage of a particular vehicle). The display of suggested routes for a particular selected vehicle in a map application will be described in more detail below.

In some embodiments, in response to user input, device 500 displays user interface 607, as shown in fig. 6B. In some implementations, the user interface 607 includes information for navigating to destination 1. In FIG. 6B, user interface 607 includes text indication 609, list 616-1, and list 616-2. In some embodiments, the text indication 609 includes an indication that the proposed route is for traveling to destination 1 and an indication that the proposed route is for traveling from "my location" to destination 1. In some embodiments, list 616-1 corresponds to proposed route 620-1 and includes a description that it takes 50 minutes to estimate to travel proposed route 620-1, that proposed route 620-1 is 43.8 miles long, and that proposed route 620-1 is the fastest route (e.g., in time, optionally including current traffic conditions). In some embodiments, list 616-2 corresponds to proposed route 620-1 and includes a description that it takes 57 minutes to estimate to travel proposed route 620-2, proposed route 620-2 is 44.5 miles long, and proposed route 620-2 is an alternative route (e.g., an alternative route to proposed route 620-1). In some embodiments, list 616-1 and list 616-2 include buttons 618-1 and 618-2, respectively, that are selectable to begin navigation along the respective suggested route. In some embodiments, list 616-1 and list 616-2 are selectable to display more information about the respective route, as will be described in more detail below.

It should be appreciated that although fig. 6B illustrates the display of two suggested routes, the apparatus 500 may display only one suggested route or may display more than two suggested routes.

In fig. 6B, contact 603B is received on user interface 607. In fig. 6C, an upward swipe 603C of contact 603B on user interface 607 is detected (e.g., from contact 603B in fig. 6B). In some implementations, in response to swipe up 603C, user interface 607 flares up according to the swipe up gesture, as shown in fig. 6C. In some embodiments, the expanded user interface 607 includes options for selecting one or more vehicles for which custom proposed routes are provided. For example, in fig. 6C, the extended user interface 607 includes a list 622 of vehicles. In some embodiments, vehicle list 622 includes vehicle options 624-1, vehicle option 624-2, and no vehicle option 624-3. In some implementations, the vehicle option 624-1 corresponds to a first vehicle that has been registered with (e.g., added to) the map application, and the vehicle option 624-2 corresponds to a second vehicle that has been registered with the map application. As shown in fig. 6C, the vehicle 1 is a fuel-fired vehicle and the vehicle 2 is an electric vehicle. In some embodiments, no vehicle option 624-3 corresponds to no particular vehicle, and selection of vehicle option 624-3 causes the map application to suggest a route that is selected without consideration of particular vehicle characteristics (e.g., such as a fuel type for a particular vehicle or a fuel and/or charge level for a particular vehicle), such as described above in connection with fig. 6B.

In some embodiments, the vehicle options 624-1 include a textual description 626-1 of the fuel vehicle 1 (e.g., name, brand, model, etc. of the vehicle). In some embodiments, the vehicle options 624-1 include an indication 628-1 of how much fuel the vehicle is currently (e.g., for a fuel-fired vehicle) and/or how much electricity is charged (e.g., for an electric vehicle). In some embodiments, the map application receives current fuel and/or power information from another application or server, as will be described in more detail below in connection with method 900. In some embodiments, the vehicle options 624-2 include a textual description 626-2 of the electric vehicle 2 (e.g., name, brand, model, etc. of the vehicle). In some embodiments, the vehicle options 624-2 include an indication 628-2 of how much fuel the vehicle is currently (e.g., for a fuel-fired vehicle) and/or how much electricity is charged (e.g., for an electric vehicle). It should be appreciated that if more or fewer vehicles are registered with the map application, the list of vehicles 622 will include more or fewer vehicles accordingly.

As shown in fig. 6C, an icon 627 (e.g., a check mark) indicates that the currently selected option in the vehicle list 622 is a no vehicle option 624-3, and thus no vehicle is currently selected.

It should be appreciated that although fig. 6C shows two vehicles (vehicle 1 as a fuel vehicle and vehicle 2 as an electric vehicle) being registered with the map application, more or fewer vehicles may be registered with the map application. For example, before the user has added any vehicles to the map application (e.g., manually or by linking with a vehicle application, such as described below in connection with method 900), vehicle list 622 does not include vehicles but only includes no vehicles option 626-3 (or optionally, vehicle list 622 is not included in user interface 607). In response to adding a vehicle, the vehicle list 622 may have one or more vehicles corresponding to the added vehicle. For example, after adding a vehicle, vehicle list 622 may have a vehicle list and no vehicle list 626-3. In some embodiments, any vehicle in the list 622 of vehicles may be any fuel type vehicle (e.g., a fuel-fired vehicle, a hybrid vehicle, a plug-in hybrid vehicle, a hydrogen energy vehicle, a fuel cell vehicle, an electric vehicle, a solar vehicle, etc.). It should also be appreciated that although vehicle 1 is shown as a fuel-fired vehicle and vehicle 2 is shown as an electric vehicle, this is merely exemplary and that vehicle 1 and vehicle 2 may be any fuel-type vehicle.

Fig. 6D to 6V show embodiments in which a suggested route is displayed based on the selected vehicle characteristics. For example, the map application (or optionally the navigation server described above with which the map application communicates) can determine whether the selected vehicle requires recharging or refueling to reach the destination. It should be understood that the features described below for the fuel vehicle 1 and the electric vehicle 2 are not limited to only the type of vehicle for which the features are described (e.g., the features described for the fuel vehicle 1 are not limited to only the fuel vehicle, and the features described for the electric vehicle 2 are not limited to only the electric vehicle), and any or all of the features described for the fuel vehicle 1 may be applied to the electric vehicle 2, and vice versa. In addition, the features described for the fuel-fired vehicle 1 and the electric vehicle 2 are applicable to any type of vehicle (e.g., a lead-free gasoline vehicle, a diesel vehicle, a hybrid vehicle, a plug-in hybrid vehicle, an electric vehicle, a fuel cell vehicle, a hydrogen-energy vehicle, etc.) having any fuel type.

In FIG. 6D, a user input 603D is received selecting a vehicle option 624-1 corresponding to the fuel-fired vehicle 1. In some embodiments, in response to user input 603d, the fuel vehicle 1 becomes the selected vehicle, as shown in fig. 6E. In fig. 6E, because the proposed route is provided by the map application when the user selects the fuel vehicle 1, the proposed route is updated to be customized for the fuel vehicle 1 (optionally, if the proposed route is not provided by the map application when the user selects the fuel vehicle 1, the proposed route is not updated). In some embodiments, the customized route of the vehicle is selected based on at least some of the characteristics of the selected vehicle (e.g., one characteristic, two characteristics, etc.). Thus, in FIG. 6E, the proposed route 620-2 and the proposed route 620-3 are selected based on the characteristics of the fuel vehicle 1. In some embodiments, the proposed route is selected based on the current fuel level of the fuel vehicle 1. In some embodiments, the proposed route is selected based on an estimated range of the fuel vehicle 1 (e.g., a distance that the fuel vehicle 1 may travel with a current amount of fuel without fueling).

As shown in FIG. 6E, the proposed route 620-3 is the main recommended route (e.g., the first listed route and displayed in a prioritized visual representation) and includes a proposed parking spot 632-1. In some embodiments, suggested parking spot 632-1 is an icon representing a gas station and indicates a recommended and/or required parking spot to refuel fuel vehicle 1 to reach the destination. In some implementations, the proposed parking spot 632-1 is located at a position on the proposed route 620-3 that corresponds to the position of the respective gas station. In some embodiments, the fueling stop that should be suggested is determined based on the estimated range of the fuel vehicle 1. In some embodiments, stopping is recommended if the estimated range of the fuel vehicle 1 is insufficient to reach the destination. In some embodiments, if the fuel vehicle 1 will have less than a threshold amount of fuel (e.g., less than 5%, 10%, 15%, 20%, etc. of fuel) or less than a threshold number of estimated remaining miles (e.g., less than 5 miles, 10 miles, 20 miles, 30 miles, 50 miles, etc.) upon reaching the destination, a proposed stopping point is recommended. As described below, the proposed parking spot 632-1 is a gas station based on the fact that the fuel vehicle 1 requires fuel to travel, but the proposed parking spot may be any type of gas station or charging station based on the type of vehicle proposed for the proposed parking spot (e.g., electric vehicle, hydrogen energy vehicle, E85 vehicle, diesel vehicle, etc.).

In some embodiments, the list 616-1 corresponding to the proposed route 620-3 includes an indication 630-1 indicating that the proposed route 620-3 includes one of the parking spots in the Echo Park (e.g., the name of the area in which the fueling station is located). In some embodiments, list 616-2 corresponding to proposed route 620-2 includes an indication 630-2 indicating that proposed route 620-2 includes one of the waypoints in plaasantville. In some embodiments, the list 616-1 and the list 616-2 include an indication of an estimated length of time to travel along the respective suggested route. In some embodiments, the estimated duration includes an estimated duration to refuel the vehicle to a recommended level. In some embodiments, proposed route 620-2 does not include a representation or icon of a proposed parking spot, even though proposed route 620-2 does include a proposed parking spot. In some embodiments, only the first listed (e.g., the most recommended, or currently selected, or highlighted route) suggested parking spots include an icon of suggested parking spots, while other suggested routes do not include icons of suggested parking spots, even if the suggested routes include suggested parking spots (e.g., any or all of the other suggested parking spots). In some embodiments, all of the displayed suggested routes include an icon or indication of a suggested parking spot (e.g., not just the first suggested route). As shown in fig. 6E, in some embodiments, one or more of the custom proposed routes are the same as the non-custom proposed route. For example, the proposed route 620-2 in fig. 6E is the same as the proposed route 620-3 in fig. 6B (e.g., optionally, except that the proposed route 620-2 in fig. 6E includes a proposed parking spot). In some embodiments, proposed route 620-3 is a route that would not otherwise be proposed when no vehicle is selected (e.g., as in fig. 6B).

In FIG. 6E, user input 603E is received selecting a list 616-1 corresponding to the proposed route 620-3. In some embodiments, in response to user input 603e, device 500 displays user interface 634, as shown in fig. 6F. In some embodiments, user interface 634 includes one or more step-wise directions to travel from the current location of device 500 to destination 1 via suggested route 620-3. In fig. 6F, user interface 634 includes steps 636-1 through 636-7 for traveling from a starting location to a destination location.

In some embodiments, one or more steps include an indication of the amount of fuel and/or the amount of electricity that the vehicle will or should have when the vehicle reaches or follows the respective step. For example, step 636-1 (e.g., a starting step) corresponding to the starting location includes an indication 638-1 of an estimated fuel amount that the fuel vehicle 1 will have at the starting location. In some embodiments, indication 638-1 includes an indication of the current amount of fuel (e.g., because step 636-1 is the first step). In some embodiments, step 636-4, which corresponds to a proposed parking spot (e.g., proposed parking spot 632-1 at fueling station in Echo Park to fueling), includes an indication 638-2 of a recommended amount of fuel to fueling the fuel vehicle 1 until the destination is reached (optionally, the destination is reached with a threshold amount of fuel or remaining range). In some embodiments, step 636-7, which corresponds to the arrival step at the destination, includes an indication 638-3 indicating an estimated amount of fuel (e.g., 5/16 of a tank) that the fuel vehicle 1 will have when it arrives at the destination. It should be appreciated that more or fewer steps may include an indication of estimated fuel quantity (e.g., zero, one, or more steps include an indication of estimated fuel quantity, optionally, zero, one, or more other steps do not include an indication of estimated fuel quantity), and any of steps 636-1 through 636-7 may include an indication of estimated fuel quantity when reaching or after the respective step.

In fig. 6F, a user input 603F is received selecting the "done" button. In some embodiments, in response to user input 603f, user interface 634 is dismissed (e.g., display ceases), as shown in fig. 6G.

In fig. 6G, contact 603G is received on user interface 607. In fig. 6H, an upward swipe 603H of contact 603G on user interface 607 (e.g., an upward swipe from contact 603G in fig. 6G) is detected, resulting in an expanded user interface 607 being displayed. In fig. 6I, upon displaying the expanded user interface 607, a user input 603I is received selecting a list 626-2 corresponding to electric vehicle 2. In some embodiments, in response to user input 603i, electric vehicle 2 becomes the selected vehicle, as shown in fig. 6J. In some embodiments, because the proposed route is displayed by the map application upon receipt of the user input 603I in fig. 6I, the proposed route is updated to be customized for the electric vehicle 2. For example, in FIG. 6J, user interface 600 includes suggested route 620-1 and suggested route 620-2. As shown, the proposed route 620-1 and the proposed route 620-2 are the same route proposed in fig. 6B because it is the electric vehicle 2 that has sufficient power (e.g., 73% of the power) to reach the destination. Thus, even if the device 500 considers the state of charge of the electric vehicle 2, the proposed route may optionally be the same proposed route as when the device 500 does not consider the state of charge (e.g., when the device 500 proposes a route without selecting a vehicle).

Fig. 6K shows an embodiment in which the electric vehicle 2 does not reach a sufficient amount of electricity (for example, 23% of the amount of electricity) of the destination. In such an embodiment, the user interface 600 includes a suggested route 620-4 and a suggested route 620-5. In some embodiments, proposed route 620-4 includes proposed parking spot 632-2 corresponding to a proposed parking spot for charging electric vehicle 2 at an electric vehicle charging station. In some embodiments, the suggested parking spot 632-2 is recommended because the electric vehicle 2 does not have sufficient power to reach the destination (or, optionally, will not have sufficient power to reach the destination with a threshold amount of remaining power or remaining range). In some embodiments, suggested parking point 632-2 is selected based on a charging station network compatible with electric vehicle 2, as will be described in detail below in connection with method 900. In some embodiments, the proposed parking spot 632-2 in fig. 6K is an electric vehicle charging station based on the fact that the electric vehicle 2 needs to be charged to travel, but the proposed parking spot may be any type of gas station or charging station based on the type of vehicle proposed for the proposed parking spot (e.g., fuel vehicle, hydrogen energy vehicle, E85 vehicle, diesel vehicle, etc.).

As shown in fig. 6K, proposed route 620-4 is a different route than proposed route 620-1 and proposed route 620-2 because device 500 has determined that a charging stop is required. Thus, the suggested route 620-4 navigates the user to the suggested charging stop before navigating the user to the destination. In some embodiments, the proposed route 620-4 differs from the proposed route 620-3 in that the electric vehicle 2 requires an electric vehicle charging stop rather than a gas station stop. Thus, the apparatus 500 can take into account the state of charge of the electric vehicle 2 and the type of parking spot required based on the type of fuel (e.g., electricity rather than fuel) of the electric vehicle 2. Similarly, proposed route 620-5 is different from proposed route 620-1, proposed route 620-2, and proposed route 620-3 in that it is an alternative route that also includes a stopping point located at an electric vehicle charging station. In some embodiments, any proposed route for the electric vehicle 2 may have a route similar to any proposed route described above for the fuel vehicle 1 or when no vehicle is selected, but optionally includes a stopping point located at an electric vehicle charging station, for example, if a compatible electric vehicle charging station happens to follow one of the routes that would otherwise be proposed to the user of the electric vehicle 2.

In some embodiments, the list 616-1 corresponding to the proposed route 620-4 includes an indication 630-1 indicating that the proposed route 620-3 includes one parking spot in Echo Park (e.g., the name of the area in which the charging station is located). In some embodiments, list 616-2 corresponding to proposed route 620-5 includes an indication 630-2 indicating that proposed route 620-5 includes one of the stops in the silnt Hill. In some embodiments, the proposed route 620-5 does not include a representation or icon of a proposed parking spot, even though the proposed route 620-5 does include a proposed parking spot. In some embodiments, only the first listed (e.g., the most recommended route or the currently selected or highlighted route) suggested parking spots include an icon of suggested parking spots, while other suggested routes do not include icons of suggested parking spots, even though the suggested routes include suggested parking spots (e.g., any or all of the other suggested parking spots). In some embodiments, all of the displayed suggested routes include an icon or indication of a suggested parking spot (e.g., not just the first suggested route). As shown in fig. 6K, the indication (e.g., icon) of the suggested parking spot 632-2 is a representation of an electric vehicle charging station and is a different icon than the suggested parking spot 632-1 (representation of a gas station) shown in fig. 6G. In some embodiments, the icon representing the proposed parking spot along the route is the same whether the proposed parking spot is an electric vehicle charging station or a gas station.

In FIG. 6K, user input 603K is an input selecting list 616-1 corresponding to suggested route 620-4. In some embodiments, in response to user input 603k, device 500 displays user interface 634, as shown in fig. 6L. In some implementations, the user interface 634 includes one or more step-wise directions to travel from the current location or selected starting location of the device 500 to destination 1 via the suggested route 620-4. In fig. 6L, user interface 634 includes steps 636-1 to 636-6 for traveling from a starting location to a destination location.

In some embodiments, as shown in fig. 6L, one or more of steps 636-1 through 636-6 include an indication of the amount of power that the electric vehicle 2 will have or should have when the vehicle reaches the location of the respective step (e.g., if the vehicle follows a planned route). For example, step 636-1 (e.g., a starting step) corresponding to the starting location includes an indication 638-1 of an estimated amount of power that the electric vehicle 2 will have at the starting location. In some embodiments, the indication 638-1 includes an indication of the current charge (e.g., because step 636-1 is the first step). In some embodiments, step 636-4, which corresponds to the proposed parking spot of fig. 6K (e.g., proposed parking spot 632-2 at an electric vehicle charging station in Echo Park to recharge), includes an indication 638-2 of the recommended amount of power to recharge the electric vehicle 2 until the destination is reached (optionally, the destination is reached with a threshold amount of power or remaining range). In some embodiments, step 636-6, which corresponds to the step of arriving at the destination, includes an indication 638-3 indicating an estimated amount of power (e.g., 38% of battery remaining) that the electric vehicle 2 will have when arriving at the destination. It should be appreciated that more or fewer steps may include an indication of estimated charge, and any of steps 636-1 through 636-6 may include an indication of estimated charge to the corresponding step or after the corresponding step.

In fig. 6L, a user input 603L is received selecting the "done" button. In some embodiments, in response to user input 603l, user interface 634 is dismissed (e.g., display ceases), as shown in fig. 6M. In FIG. 6M, user input 603M selecting button 618-1 is received for starting navigation using suggested route 620-4. In some embodiments, in response to user input 603m, device 500 begins a navigation mode and displays user interface 640, as shown in fig. 6N.

In some embodiments, the navigation mode includes displaying a step-wise and/or turn-by-turn guidance of travel along the respective route. In some embodiments, step-by-step and/or direction-by-direction guidance is provided based on the location of the device to provide real-time guidance to the user to the destination. In fig. 6N, user interface 640 includes instructions 642 and instructions 644. In some implementations, the instructions 642 include text instructions corresponding to the currently displayed step. For example, in fig. 6N, instruction 642 instructs the user to start traveling at Main St. In some implementations, the instructions 644 provide additional instructions associated with the displayed step or provide a preview of the next step. For example, in FIG. 6N, instruction 644 indicates that the next step is to turn left in Ocean Ave. As shown in fig. 6N, any of instructions 642 and/or 644 may include an icon (e.g., a turn icon, a start icon, etc.) representing a step. In some implementations, the instructions 644 are not displayed for some steps or for all steps (e.g., if additional information is not needed).

In some implementations, the user interface 640 includes a representation of a map that includes the current location of the device 500 as shown by the location indicator 646. As shown in fig. 6N, the location indicator 646 indicates a current location of the device 500 (e.g., on a representation of a map corresponding to the current location of the device 500) and/or an orientation of the device 500 (e.g., an arrow in the location indicator 646 faces in a direction of the orientation of the device 500). In some implementations, the user interface 640 includes a route 648 that corresponds to the proposed route 620-4. In some implementations, the representation of the map is oriented such that the map faces the direction in which the device 500 faces. For example, in fig. 6N, if the device 500 is facing south, the representation of the map is oriented such that south is facing upward.

In some embodiments, user interface 640 includes a user interface 650 that is displayed overlaid on user interface 640. In some implementations, the user interface 650 provides general information of the proposed route 620-4. For example, in fig. 6N, user interface 650 includes an indication 652, an indication 654, and a button 656. In some implementations, the indication 652 displays an estimated time to reach a next stopping point (e.g., a suggested stopping point, a destination, or a user-selected stopping point along a suggested route). In some embodiments, the indication 654 displays an estimated amount of power that the electric vehicle 2 will have when reaching the next stopping point. In some implementations, the button 656 is selectable to end the navigation mode (e.g., to stop providing step-wise or turn-by-turn instructions to the destination).

FIG. 6O shows an embodiment in which the user has traveled along the proposed route 620-4 and is approaching a proposed charging stop along the proposed route 620-4. In some implementations, the device 500 uses one or more device location mechanisms or processes (e.g., using a GPS locator on the device 500, etc.) to determine that the user has traveled along the proposed route 620-4 and is approaching a proposed charging stop (e.g., the proposed stop 632-2 from fig. 6K, represented by representation 660). In fig. 6O, instruction 642 is updated to indicate that the proposed charging stop is 400 feet forward of the left side of the road. In some embodiments, the instructions 644 are updated to provide additional information regarding suggested charging stops (e.g., the charging station is located at the first floor). In some embodiments, if the proposed stop point is to refuel at a gas station (e.g., for a fuel vehicle), the instructions 644 can be updated to provide additional information about the gas station (e.g., which pump to use, which level of fuel to use, where the pump is located, etc.).

In some implementations, the user interface 640 includes a route 648 that corresponds to the upcoming route. In some implementations, the user interface 640 includes a route 658 corresponding to the traversed route. Between route 648 and route 658, there may be a representation (e.g., indicator 646) of the current location of the user vehicle. In some implementations, the user interface 640 includes a representation 660 corresponding to a suggested parking spot (e.g., suggested parking spot 632-2 from fig. 6K). In some implementations, representation 660 is displayed at a location on a representation of the map that corresponds to the suggested parking spot location. As shown in fig. 6O, representation 660 is an icon of an electric vehicle charging station. In some embodiments, representation 660 includes a textual description of the proposed parking spot (e.g., a name of the proposed parking spot, a name of the charging station, a charging network associated with the charging station, etc.).

Fig. 6P shows an embodiment in which the user has reached the proposed charging stop (or optionally within a threshold distance from the proposed charging stop, such as 50 feet, 100 feet, 300 feet, 500 feet, 1500 feet, etc.). In some embodiments, instructions 642 are updated to indicate that the user has reached the suggested parking spot. In some embodiments, instructions 644 are updated to suggest to the user to use adapter 1 to convert a plug used by electric vehicle 2 to a plug type compatible with the charging station. In some embodiments, the adapter 1 is determined to be needed to convert a plug type installed on the electric vehicle 2 to a plug type compatible with the charging station based on the received information about the electric vehicle 2, as described below in connection with the method 900 (e.g., information about compatible plug types, information about available adapters, etc.). It should be appreciated that providing information regarding the required adapter may be applicable to other fuel type vehicles (e.g., gasoline vehicles, electric vehicles, hybrid vehicles, plug-in hybrid vehicles, etc.).

Fig. 6Q shows an embodiment in which the device 500 has determined that the electric vehicle 2 is charging. In some implementations, the device 500 receives information about the state of charge from a source external to the map application (e.g., an application other than the map application, or a server external to the device 500), as described below in connection with the method 900. In some embodiments, instructions 642 are updated to instruct the user to charge electric vehicle 2 to at least 53% and the charge estimate takes 15 minutes. In some implementations, the estimated remaining charge time is determined based on information received from a source external to the map application.

In some implementations, in response to determining that the electric vehicle 2 is charging, the user interface 640 is updated to display a route 648 corresponding to the forward route to the destination. In fig. 6Q, the user interface 650 is updated to include a button 662. In some implementations, the button 662 is selectable to pause the navigation mode (e.g., when the vehicle is charging). In some embodiments, the pause navigation mode returns the map application to a browsing mode in which the user can interact with the representation of the map and search for a location (and optionally easily resume the navigation mode, as described below), such as shown in fig. 6A. In fig. 6Q, user input 603Q selecting button 662 is received. In some embodiments, in response to user input 603q, device 500 pauses (e.g., terminates, ends, or stops) the 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 the electric vehicle 2 is charging (e.g., optionally after a user pauses the navigation mode via select button 662, after a user locks the device 500 or places the device 500 in a low power mode, or after navigating away from a user interface of a 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 when waking up device 500 after waking up device 500 from a low power mode. In some embodiments, when navigation is paused (e.g., previously terminated, ended, or stopped) and when the electric vehicle 2 is charging, the device 500 displays a notification 668 that includes the vehicle state of charge and/or the remaining charging time. In fig. 6R, notification 668 indicates that there is an estimated remaining time of five minutes to reach the recommended charge level. In some embodiments, the suggested power level is selected based on a remaining distance to the destination (e.g., the power required to reach the destination with a threshold amount of power remaining, and/or the power required to reach the destination with a remaining range). In some embodiments, notification 668 is updated periodically (e.g., every 10 seconds, every 30 seconds, every 1 minute, every 5 minutes, every 10 minutes, etc.) to indicate an estimated remaining time to charge the vehicle to the recommended charge level. In some embodiments, notification 668 indicates the current charge level (or fuel level for a fuel-fueled vehicle, or any other relevant fuel amount for other fuel-type vehicles).

In some embodiments, notification 668 is displayed on any user interface and is not limited to only lock or wake up screen user interfaces. For example, notification 668 may be displayed when device 500 is displaying a system user interface (e.g., home screen user interface, application launch user interface, setup user interface) or a user interface of an application. In some embodiments, notification 668 may be displayed on a notification user interface (e.g., a user interface including one or more activity notifications). In some embodiments, notification 668 is persistent and remains displayed on the lock or wake screen user interface (and optionally on the notification user interface) while electric vehicle 2 is charging. In some embodiments, in accordance with a determination that electric vehicle 2 has stopped charging, notification 668 is automatically dismissed (e.g., removed from lock or wake screen user interface 664 and/or notification user interface). In some embodiments, notification 668 may be manually dismissed in response to user input requesting dismissal of notification 668.

Fig. 6S shows a notification 668 when the device 500 determines that the electric vehicle 2 has reached the recommended electric power level. In some embodiments, notification 668 indicates that electric vehicle 2 is ready to continue traveling toward the destination. In some embodiments, notification 668 indicates that electric vehicle 2 has reached the recommended charge level. In some embodiments, notification 668 indicates the current power level.

In some implementations, selecting notification 668 (e.g., when electric vehicle 2 is charging or after electric vehicle 2 has completed charging) initiates a process of displaying a map application (e.g., user interface 600) and/or resuming navigation (e.g., optionally after device 500 has been unlocked). In some embodiments, if electric vehicle 2 has charged beyond the recommended level, notification 668 may indicate that electric vehicle 2 has charged beyond the desired level and that electric vehicle 2 is ready to continue along the recommended route.

Fig. 6T illustrates an exemplary user interface 600 of the map application when charging the electric vehicle 2, such as in response to a user selection of the button 662. In some embodiments, the user interface 606 includes an indication 672 to recharge the electric vehicle 2 for 15 minutes. In some embodiments, the indication 672 is updated periodically (e.g., every 10 seconds, every 30 seconds, every 1 minute, every 5 minutes, every 10 minutes, etc.) to indicate an estimated remaining time to charge the vehicle to the recommended charge level. In some embodiments, the indication 672 indicates the current charge level. In some embodiments, for other fuel type vehicles, the indication 672 indicates a current fuel level (e.g., fuel level for a fuel vehicle, etc.).

Fig. 6U shows an indication 672 when the device 500 determines that the electric vehicle 2 has reached the recommended electric power level. In some embodiments, the indication 672 indicates that the electric vehicle 2 is ready to continue traveling toward the destination. In some embodiments, the indication 672 indicates that the electric vehicle 2 has reached a recommended charge level. In some implementations, the indication 672 is selectable to resume the navigation mode (e.g., and optionally display the user interface 640).

In fig. 6U, a user input 603U of a selection indication 672 is received. In some embodiments, in response to user input 603u, device 500 resumes the navigation mode of suggested route 620-4 and displays user interface 640, as shown in fig. 6V. Similarly, in response to selection of notification 668 shown in FIG. 6S, the navigation mode of suggested route 620-4 may optionally be resumed. In some embodiments, selecting notification 668 or indication 672 does not result in a resumption of navigation mode before the vehicle has reached the recommended power level. In some embodiments, selecting notification 668 or indication 672 before the vehicle has reached the suggested charge level does result in restoration of the navigation mode (but optionally may result in the addition of another suggested parking spot, such as described below in connection with fig. 6V).

Fig. 6V illustrates an embodiment in which the device 500 determines that one (or another) fueling and/or charging stop point is required to reach the destination while in the navigation mode. In some embodiments, fueling and/or charging stops are not previously recommended, but are now recommended based on updated information. For example, based on the updated information, the device 500 determines that the electric vehicle 2 will not be able to reach the destination (or, optionally, will reach the destination with less than a threshold amount of power or less than a threshold amount of remaining range). In some embodiments, the updated information is an updated estimated range of the electric vehicle 2 and/or an updated power level of the electric vehicle 2, such as described in connection with the method 900. For example, in fig. 6V, the apparatus 500 determines that the electric vehicle 2 has only 10% of the remaining power and may not reach the destination. In some embodiments, if the initial estimated range is inaccurate, a stopping point is suggested because the vehicle's economy of travel changes (e.g., due to aggressive driving or wild driving), because the electric vehicle 2 does not follow the suggested route, or any other potential cause.

In some embodiments, in response to determining that a fueling and/or charging waypoint is required, the device 500 determines (or the navigation server determines) an appropriate suggested waypoint and determines whether the route should be modified. For example, in FIG. 6V, user interface 640 is updated to display route 648 including suggested parking spot 684. As shown in fig. 6V, route 648 is a modified route to the same destination including the suggested parking spot. In some implementations, the display route 648 is an indication of a suggested route. In some implementations, a route 682 corresponding to the initial proposed route (e.g., no proposed stopping point) is displayed. In some embodiments, the user interface 674 is displayed to indicate a recommended parking spot and to request confirmation whether the recommended parking spot is added to the navigation route. In some embodiments, the user interface 674 includes a text indication 676 that indicates that a charging stop is needed or suggested because there is insufficient power to reach the destination. In some embodiments, the user interface 674 includes a button 678 that is selectable to dismiss the user interface 674, refuse to add a suggested parking spot, and continue along an initial route (e.g., along route 682). In some embodiments, the user interface 674 includes a button 680 that is selectable to confirm the addition of a proposed parking spot and navigate along the route 648 (including parking at the proposed parking spot). In some embodiments, for vehicles of other fuel types (e.g., gasoline, hydrogen, E85, etc.), the apparatus 500 may display a suggested parking spot to charge and/or refuel at a compatible station.

Fig. 6W to 6FF show an embodiment in which a suggested route is selected based on characteristics of the corresponding vehicle with respect to a travel limit. In fig. 6W, the device 500 displays a user interface 600 of the map application and a user interface 606. In fig. 6W, the user interface 600 does not include any suggested route or travel guidance, and is optionally the default user interface of the map application (e.g., while in a browsing state) that includes the location indicator 602. In some implementations, the user interface 606 includes a search field 670. In some embodiments, the user interface 606 includes an indication 686. In some embodiments, indication 686 is displayed in accordance with a determination that the current location of device 500 is within or near a geographic area where a travel limit exists.

In the embodiment shown in fig. 6W to 6FF, the corresponding travel limit is based on the license plate of the vehicle, but it should be understood that any travel limit is possible. In some embodiments, the travel limit corresponds to a limit that defines that a particular group of vehicles may travel unrestricted and that a second group of vehicles is restricted from traveling. In some embodiments, other restrictions are possible (e.g., a first set of vehicles must follow a particular set of rules or regulations, while a second set follows a different set of rules or regulations, or all vehicles with particular characteristics are restricted from traveling, etc.). For example, if a particular region or road group is subject to travel restriction control, certain vehicles having certain characteristics defined by the restriction may be restricted to travel within the region (or on the road), while other vehicles without these certain characteristics may not be restricted to travel within the region (or on the road). For example, there may be a limit in which an odd license plate (e.g., a vehicle with an odd license plate tail number) is prohibited from traveling at a particular location during a particular time and date, and an even license plate (e.g., a vehicle with an even license plate tail number) is not prohibited from traveling at a particular location at any time (or from traveling at a particular location during other times). Another example of a travel limit may be to prohibit vehicles exceeding a certain total weight from traveling on a certain highway during business hours, and not to prohibit vehicles below the total weight threshold from traveling on the highway.

In some embodiments, the indication 686 includes an affordance 688 that is selectable to provide one or more license plates to the map application. In some implementations, the indication 686 is only displayed if no license plates have been provided to the map application. Thus, in some implementations, the indication 686 is not displayed after the user has added the first vehicle license plate to the map application (optionally, even though the current location of the device 500 is within or near the geographic area where the travel limit exists). In some embodiments, if the current location of the device 500 is within or near a geographic area where there is a travel limit that is not based on the vehicle license plate, an indication 686 may be displayed and the user is advised to provide other characteristic information for his vehicle (e.g., based on the height, width, number of axles, weight, or any other suitable characteristic of the vehicle, etc.) even though the user has added the license plate to the map application. In some embodiments, the process for adding vehicles, registering vehicles, and/or providing license plate information is similar to the process described below in connection with fig. 8D-8H.

Fig. 6X shows an embodiment in which a suggested route is provided to a user with respect to a travel limit. In some embodiments, if the user requests directions to the destination and one or more routes require the user to travel through the area subject to travel restrictions, the user interface 600 includes an indication 698 of the area subject to travel restrictions. In some implementations, the indication 698 is a visual element that visually distinguishes a geographic region subject to travel restriction from a region not subject to travel restriction (e.g., in gray, with a fill pattern, etc.).

In some embodiments, as shown in FIG. 6X, user interface 600 includes suggested route 620-6 and suggested route 620-7. In some embodiments, route 620-6 is suggested to travel through a geographic area subject to travel restrictions. In some embodiments, proposed route 620-6 includes an indicator 692 located on a boundary of a geographic area subject to travel restrictions to indicate that the user may become subject to travel restrictions at the location indicated by indicator 692. In some embodiments, tab 690-1 corresponding to proposed route 620-6 indicates that proposed route 620-6 is the fastest route (and is estimated to take 30 minutes) and includes an icon indicating that a travel limit is likely to be applied to the user's vehicle.

In some embodiments, proposed route 620-7 travels around a geographic area that is subject to travel restrictions and does not include an indicator that indicates that the user may be subject to travel restrictions. In some embodiments, tab 690-2 corresponding to proposed route 620-7 indicates that proposed route 620-7 avoids the travel limit. As shown in fig. 6X, no vehicle is currently selected, and thus the device 500 does not have license plate information for vehicles that the user intends to use to travel along the proposed route. Thus, in some embodiments, the device 500 provides at least one route selected to avoid the travel limit (e.g., the fastest route, such as suggested route 620-6) and at least one route selected to avoid the travel limit (e.g., the fastest route that avoids the travel limit, such as suggested route 620-7). In some embodiments, only one proposed route is displayed (e.g., only the fastest route without consideration of the restriction or only the fastest route avoiding the restriction).

In some implementations, the user interface 606 includes a list corresponding to the proposed route 620-6

616-1 and a list 616-2 corresponding to the proposed route 620-7. In some embodiments, the list

616-1 includes an indication 630-1 that indicates that the proposed route 620-6 is subject to travel restrictions. In some embodiments, the indication 630-1 includes a link 694 that is selectable to display details regarding respective travel limits applied in respective geographic areas. In some embodiments, list 616-2 does not include an indication that proposed route 620-7 is subject to travel restrictions, but includes an indication that proposed route 620-7 avoids the travel restrictions that proposed route 620-6 is subject to.

In some embodiments, if the proposed route does not pass or pass near the restricted area, the map user interface 600 does not include an indication 698 of the area subject to the travel restriction. For example, in the embodiment shown in fig. 6B, no travel restrictions are applied in the area displayed by the representation of the map, and thus device 500 does not display an indication of a travel restriction (e.g., does not include indication 698, indication 630-1, and/or link 694).

In fig. 6Y, a user input 603Y is received that selects a link 694 corresponding to a request to display more information about the travel limit. In some embodiments, in response to user input 603y, device 500 updates user interface 607 to display information regarding the travel limit, as shown in fig. 6Z. In some embodiments, the updated user interface 607 includes a description 696 describing the applied travel limits, optionally including a description of what the limits are and which vehicles are limited. For example, in FIG. 6Z, description 696 indicates that between Tuesday and Tuesday at 7:00 am and 6:30 pm, vehicles with odd license plate tails are prohibited from traveling in a restricted area (e.g., the urban area Pleasanton). In some embodiments, as will be described in detail below, the device 500 is capable of determining whether a particular car is restricted and the time that the car is restricted, and selecting a suggested route based on the determination.

In fig. 6AA, an upward swipe 603AA of contact on the user interface 607 is detected (e.g., from the upward swipe of contact on the user interface 607 shown in fig. 6Y), resulting in an expansion of the user interface 607 (e.g., similar to fig. 6C). Similar to that described above in connection with fig. 6C, the extended user interface 607 includes a list 622 of vehicles. In some embodiments, vehicle list 622 includes vehicle options 624-1, vehicle option 624-2, and no vehicle option 624-3. In some implementations, the 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), and the 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). As shown in fig. 6AA, the vehicle 1 is a fuel-fired vehicle and the vehicle 2 is an electric vehicle. In some implementations, the no vehicle option 624-3 corresponds to no particular vehicle, and selection of the vehicle option 624-3 causes the map application to suggest a route to select without consideration of particular vehicle characteristics (e.g., without consideration of whether a particular car is restricted), such as described above in connection with fig. 6Y.

In fig. 6BB, a user input 603BB is received selecting a vehicle option 624-2 corresponding to electric vehicle 2. In some embodiments, in response to user input 603bb, electric vehicle 2 becomes the selected vehicle, as shown in fig. 6 CC. In fig. 6CC, because the suggested route is displayed when the user selects the electric vehicle 2, the suggested route is updated to be customized for the electric vehicle 2. In some embodiments, the customized route of the vehicle is selected based on license plate information of the electric vehicle 2 (e.g., vehicle characteristics described additionally or alternatively with reference to fig. 6A-6V). For example, the device 500 can determine whether the electric vehicle 2 is allowed to travel in the restricted area or is prohibited from traveling in the restricted area based on the provided license plate information of the electric vehicle 2 (e.g., optionally at a current time or optionally at a future time selected by the user based on a travel restriction rule). In fig. 6CC, the electric vehicle 2 has an odd number of license plates (e.g., an odd number of license plate tails), and is therefore prohibited from traveling in urban areas between 7:00 pm on tuesday and on thursday and 6:30 pm. Thus, in some embodiments, if the current time and day is between 7:00 am and 6:30 pm on tuesday or thursday, the proposed route is selected to avoid the restricted area (e.g., at least one proposed route avoids the restriction). For example, the proposed route 620-7 is now the first proposed route (e.g., first displayed in the user interface 607 and on a map user interface with prioritized visual characteristics). In some embodiments, the one or more proposed routes travel through the restricted area even if the electric vehicle 2 is prohibited from traveling in the restricted area. For example, the proposed route 620-6 is the fastest route, but because the proposed route 620-6 travels through a restricted area, the proposed route 620-6 is not displayed first but is displayed in a map user interface with de-prioritized visual characteristics.

In some embodiments, user input 603CC is received corresponding to a selection button 618-1 for a request to begin a navigation mode using the proposed route 620-6, as shown in FIG. 6 CC. Thus, in some embodiments, the user is able to begin navigating along a route that brings the user into the restricted area even if the selected vehicle (e.g., electric vehicle 2) is prohibited from traveling within the restricted area. In some embodiments, in response to user input 603cc, device 500 begins a navigation mode and displays user interface 640, as shown in fig. 6 DD.

Fig. 6DD shows an embodiment in which the user has traveled along the proposed route 620-6 and is approaching a restricted area boundary (e.g., within 50 feet, 100 feet, 300 feet, 500 feet, 1000 feet, 3000 feet, etc.). In some implementations, the device 500 uses one or more device location mechanisms or processes (e.g., using a GPS locator on the device 500, etc.) to determine that the user has traveled along the proposed route 620-6 and is approaching the limited area boundary. In fig. 6DD, the restricted area is visually distinguished from the unrestricted area (e.g., similar to indication 698 in fig. 6X). In some embodiments, indication 646 is displayed at or near the boundary of the restricted area, indicating the point at which the restricted area begins. In some embodiments, in response to the device 500 entering within a threshold distance (e.g., 100 feet, 300 feet, 500 feet, 1000 feet, 3000 feet, etc.) of the limit boundary location, the device 500 displays a user interface 699, and the user interface 699 optionally includes a description 697 that provides a warning that the limit area is in front. In some embodiments, the description 697 includes a brief description of the restriction (e.g., an odd license plate is affected).

As indicated above, in some embodiments, although the device 500 provides an indication and/or warning that the user is about to enter the restricted area, the device 500 does not prevent the user from entering the restricted area or the navigation or mapping functions of the restriction device as the user enters the restricted area or while the user is in the restricted area. Thus, in some embodiments, the device provides information to the user regarding the restricted area, but allows the user to make a decision whether to enter the restricted area.

Fig. 6EE to 6FF show embodiments in which a proposed route is selected for a vehicle that is not prohibited from traveling in a restricted area. In fig. 6EE, user input 603EE selecting list 624-1 from vehicle list 622 is received on extended user interface 606. In some embodiments, in response to user input 603ee, the fuel vehicle 1 becomes the selected vehicle, as shown in fig. 6 FF. In fig. 6FF, because the suggested route is displayed when the user selects the fuel vehicle 1, the suggested route is updated to be customized for the fuel vehicle 1. In some embodiments, the customized route of the vehicle is selected based on license plate information of the fuel vehicle 1. For example, the device 500 can determine whether the fuel vehicle 1 is allowed to travel in the restricted area or is prohibited from traveling in the restricted area based on the provided license plate information of the fuel vehicle 1 (e.g., optionally at a current time or optionally at a future time selected by the user based on a travel restriction rule). In fig. 6FF, the fuel vehicle 1 has an even number of license plates (e.g., the number of license plate tails is even), and is therefore not prohibited from traveling in urban area plaasanton. Thus, in some embodiments, the proposed route is selected without consideration of the limitations of the restricted area. For example, the proposed route 620-6 is the first proposed route (e.g., displayed first in the user interface 606 and on a map user interface with prioritized visual characteristics), optionally because the proposed route 620-6 is the fastest route. In some implementations, the proposed route 620-8 is an alternative route (e.g., an alternative route for the proposed route 620-6). As shown in FIG. 6FF, both the proposed route 620-6 and the proposed route 620-8 are driven into and/or through the restricted area. In some implementations, the user interface 600 does not display any indication that the proposed route is subject to a restricted area. In some embodiments, the user interface 600 further includes an indicator 698 that indicates the area of the restricted area. In some embodiments, one or more of the proposed routes for the fuel vehicle 1 are the same as the route shown in FIG. 6X (e.g., proposed route 620-6 corresponds to the fastest route). In some embodiments, one or more of the proposed routes for the fuel vehicle 1 are different from the route shown in FIG. 6X (e.g., proposed route 620-8 is different from proposed route 620-7 because proposed route 620-7 is optionally selected to avoid the restriction, while proposed route 620-8 does not need to avoid the restriction because the restriction is not applied to the fuel vehicle 1). Although fig. 6FF does not show an indication that the proposed route may be subject to a travel limit (e.g., such as in fig. 6X and 6 CC), in some embodiments, the user interface 600 includes an indication of the proposed route and list even if the fuel vehicle 1 itself is not prohibited from traveling in a limited area (e.g., in the event of a wrong selection of the fuel vehicle 1, the user can see that a limit exists).

It should be understood that while the description of the above figures describes travel limits based on corresponding vehicle license plates, the disclosure herein is not so limited. For example, the above features may be applied to travel limits based on other characteristics of the vehicle (such as the vehicle's VIN, the vehicle's height, width, length, weight, etc.). For example, if a corresponding travel limit prohibits a vehicle having more than two axles from traveling within a particular area or along a particular road, the device 500 may provide the user with a process for providing information regarding the number of axles on the user's vehicle (e.g., in a process similar to the one described above for providing license plate information), and the device 500 may use the provided information to suggest a route tailored to the user's vehicle (e.g., based on whether the user's vehicle is prohibited from traveling along the particular route).

Fig. 7 is a flow chart illustrating a method 700 of displaying a customized navigation route according to some embodiments of the present disclosure. The method 700 is optionally performed on an electronic device (such as device 100, device 300, and device 500) as described above with reference to fig. 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.

As described below, the method 700 displays a customized navigation route. The method reduces the cognitive burden on the user when interacting with the device user interface of the present disclosure, thereby creating a more efficient human-machine interface. For battery-operated electronic devices, improving the efficiency of user interaction with the user interface saves power and increases the time between battery charges.

In some embodiments, electronic device 500 (in communication with one or more input devices (e.g., a mobile device (e.g., a tablet, a smart phone, a media player, or a wearable device)) or a computer, optionally with a mouse (e.g., external), a track pad (optionally integrated or external), a touch pad (optionally integrated or external), a 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) a map user interface via the display generation component, such as user interface 600 in fig. 6A (e.g., a user interface displaying a representation of a map of a given geographic location).

In some embodiments, the display generating component is a display integrated with the electronic device (optionally a touch screen display), an external display such as a monitor, projector, television, or hardware component (optionally integrated or external) for projecting a user interface or making the user interface visible to one or more users, or the like.

In some implementations, the user interface is a user interface of a map application. In some implementations, the map user interface can be interacted with by a user to view different geographic locations or to change the zoom level of the map.

In some implementations, when displaying the map user interface, the electronic device receives (704), via one or more input devices, 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).

In some embodiments, the user selects the first geographic location and/or the second geographic location. In some implementations, the first geographic location or the second geographic location is a determined current location of the electronic device. In some implementations, the map user interface displays one or more determined routes from the first geographic location to the second geographic location. In some embodiments, the one or more routes are displayed in a map user interface. In some embodiments, the user selects a traffic mode that determines the route. For example, the electronic device can determine a travel route, a public transportation route, a transfer route, a walking route, and/or a riding route, and the like. In some embodiments, the device uses different procedures, algorithms, and/or limitations when determining the potential route, depending on the selected mode of transportation.

In some embodiments, in response to user input (706), in accordance with a determination that the first vehicle is a currently selected vehicle to which directions are displayed in a map user interface (e.g., the first vehicle is selected from one or more vehicles registered and/or added to the electronic device), the electronic device displays (708) a first suggested route from the first location to the second location in the map user interface based on a first characteristic of the first vehicle, such as suggested route 620-2 and/or suggested route 620-3 in fig. 6E based on a fuel level of the fuel vehicle 1 (e.g., displays the first suggested or suggested route from the first location to the second location).

In some embodiments, the first vehicle travels using the selected traffic mode (e.g., traveling on a road). In some embodiments, the first vehicle is a fuel-fired vehicle, a hybrid vehicle, an electric vehicle, or any automobile of any fuel type (e.g., lead-free fuel, diesel, hydrogen, ethanol, self-propulsion, electricity, solar energy, bioenergy, etc.).

In some embodiments, the first proposed route is determined based on the selected characteristics of the first vehicle. In some embodiments, the first characteristic is the type of fuel used by the vehicle (e.g., gasoline, diesel, electricity, etc.). In some embodiments, the first characteristic is the fuel economy of the vehicle (e.g., the number of miles or kilometers the vehicle can travel per unit of fuel). In some embodiments, the first characteristic is a current effective range of the vehicle (e.g., the number of miles or kilometers the vehicle is currently capable of traveling without refueling and/or charging). In some embodiments, the first characteristic is a type of vehicle (e.g., passenger car, commercial car, truck, semi-trailer, etc.). In some embodiments, the first characteristic is the weight of the vehicle (e.g., a vehicle having a certain current total weight). In some embodiments, the first characteristic is a size of the vehicle (e.g., a vehicle having a height gap, a vehicle having a width gap, etc.). In some embodiments, the first characteristic is the power (e.g., horsepower, torque, etc.) of the vehicle. In some embodiments, the first characteristic is an identifier of the vehicle (e.g., a license plate number, a Vehicle Identification Number (VIN), a serial number, etc.). In some implementations, the first proposed route is determined based on a selected ability of the first vehicle to traverse a potential route from the first location to the second location (e.g., based on a value of the first characteristic). For example, if the first vehicle is an electric vehicle having a range of 100 miles and all routes from the first location to the second location exceed 100 miles, the first proposed route includes a stopping point (e.g., at an EV charging station) for charging the battery to enable the first vehicle to reach the second location. In another example, if the first vehicle is an electric vehicle having a range of 100 miles and the fastest route from the first location to the second location is less than 100 miles, the first proposed route does not include a stopping point for charging the battery. In another example, if the first vehicle is a fuel vehicle having a 250 mile travel and all routes from the first location to the second location exceed 250 miles, the first proposed route includes a stop (e.g., at a gas station) for purchasing fuel to fill the fuel tank. In another example, if the first vehicle is a semi-trailer truck having a total weight exceeding a threshold amount, the first proposed route automatically excludes roads and streets having a maximum weight limit below the total weight of the vehicle. In some embodiments, if the first vehicle is not an off-road vehicle and/or cannot traverse difficult terrain, the first proposed route does not include a route that the vehicle would not be able to traverse. In some embodiments, if the first vehicle is a wide or high vehicle, the first proposed route does not include a route requiring a narrow or low clearance. These and other characteristics are contemplated that affect the ability of the vehicle to travel from one location to another. In some implementations, the information regarding the first characteristic of the first vehicle is received from a source external to the map application, as described below in connection with method 900.

In some embodiments, in accordance with a determination that a second vehicle different from the first vehicle is a currently selected vehicle to which directions are displayed in the map user interface (e.g., a vehicle different from the first vehicle that is traveling using the same traffic pattern (e.g., traveling on a road)), the electronic device displays (710) a second proposed route different from the first proposed route from the first location to the second location in the map user interface based on a second characteristic of the second vehicle, such as proposed route 620-4 and proposed route 620-5 based on a current power level of electric vehicle 2 in fig. 6K (e.g., for the same traffic pattern (e.g., traveling on a road) that would be used with the proposed route of the first vehicle).

In some embodiments, the second vehicle is a fuel-fired vehicle, a hybrid vehicle, an electric vehicle, or any automobile of any fuel type (e.g., lead-free fuel, diesel, hydrogen, ethanol, self-propulsion, electricity, solar energy, bioenergy, etc.). In some embodiments, the second proposed route is determined based on a selected characteristic of the second vehicle. In some embodiments, the one or more characteristics of the second vehicle are different from the one or more characteristics of the first vehicle, which results in the second proposed route being different from the first proposed route. In some embodiments, the second proposed route takes a different route than the first proposed route. In some embodiments, the second proposed route includes more or fewer stopping points than the first proposed route. In some embodiments, 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. For example, the first vehicle and the second vehicle are optionally both fuel vehicles (e.g., the same fuel type) but have different effective mileage (e.g., the first vehicle has enough fuel to travel 100 miles and the second vehicle has enough fuel to travel 50 miles). In such embodiments, the proposed route of the first vehicle is different from the proposed route of the second vehicle based on the distance between the first location and the second location and whether a stop is required to purchase fuel. In some embodiments, the second characteristic of the second vehicle is a different type of characteristic than the first characteristic of the first vehicle. For example, the first vehicle is optionally a fuel-fired vehicle and the second vehicle is optionally an electric vehicle (e.g., a different fuel type), and the first proposed route does not consider the effective range of the first vehicle, while the second proposed route considers the effective range of the second vehicle. In such embodiments, if a stop is required to charge the second vehicle in order to reach the destination, the proposed route of the second vehicle is optionally different from the proposed route of the first vehicle. In some embodiments, a particular license plate pattern is limited in a particular geographic area, and the device is able to suggest routes based on applicable restrictions. For example, some geographic areas may limit travel based on whether the vehicle license plate is even or odd. In such examples, if the first vehicle has an odd number (e.g., the tail number is odd) and the second vehicle has an even number (e.g., the tail number is even), the electronic device optionally suggests a first route for the first vehicle based on whether the odd number license plate is currently limited, and optionally suggests a different second route for the second vehicle based on whether the even number license plate is currently limited. In some implementations, the information regarding the second characteristic of the second vehicle is received from a source external to the map application, as described below in connection with method 900.

The above-described manner of displaying different routes based on characteristics of different vehicles for the request guidance (e.g., by automatically considering characteristics of the vehicles when suggesting routes) quickly and efficiently provides an appropriate route for travel from a first location to a second location, which simplifies interaction between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to individually determine whether the user vehicle can traverse the route unimpeded or does not require the user to manually edit the route to take into account specific characteristics of the vehicle), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the first characteristic of the first vehicle includes a first current estimated range of the first vehicle, such as in fig. 6E (e.g., the first characteristic is an estimate of the distance the first vehicle can travel at a current fuel or charge level). In some embodiments, the estimated value of the distance that the first vehicle can travel depends on the current fuel or power level, the vehicle's travel efficiency, the first vehicle's most recent travel pattern, and/or the driver's habits, etc.

In some embodiments, the first proposed route is based on a first current estimated range, such as in fig. 6E (e.g., the first proposed route is selected based on an estimate of the distance the first vehicle can travel at a current fuel or charge level). In some embodiments, the first proposed route includes a proposed stopping point to refuel or charge the vehicle (e.g., at a gas station or an electric vehicle charging station) if the first current estimated range is insufficient to cause the first vehicle to reach the second location from the first location. In some embodiments, the first proposed route includes a proposed stopping point for fueling or charging 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., or less than 2 miles, 5 miles, 10 miles, 20 miles, 50 miles, etc., of remaining fuel or charge). Thus, in some embodiments, even if the current estimated range of the first vehicle is sufficient to reach the second location from the first location, if the first vehicle would otherwise leave with less than a threshold amount of fuel or electricity, the device will include a suggested parking spot to refuel or charge the first vehicle. In some embodiments, the first proposed route is selected to be less than an estimated value of the distance that the first vehicle is able to travel (e.g., even if it is a slower route). In some embodiments, for example, if the estimated range is approaching a distance from the first location to the second location, the first proposed route is selected to improve the driving economy of the first vehicle (e.g., a route with more stable driving is selected, etc.).

In some embodiments, the second characteristic of the second vehicle includes a second current estimated range of the second vehicle that is different from the first current estimated range, such as in fig. 6K (e.g., the current estimated range of the second vehicle is different from the current estimated range of the first vehicle). In some embodiments, the current estimated range of the second vehicle is different from the first vehicle because the vehicles have different amounts of fuel or electricity and/or the vehicles have different travel efficiencies (e.g., fuel or electricity efficiencies).

In some embodiments, the second proposed route is based on a second current estimated range, such as in fig. 6K (e.g., the second proposed route is selected based on an estimate of the distance the second vehicle can travel at the current fuel or charge level). In some embodiments, the second proposed route includes a proposed stopping point to refuel or charge the vehicle (e.g., at a gas station or an electric vehicle charging station) if the second current estimated range is insufficient to enable the second vehicle to reach the second location from the first location. In some embodiments, the second proposed route is the same route as the first proposed route (e.g., optionally the same route with the same proposed stopping point). In some embodiments, the second proposed route is a different route than the first proposed route (e.g., optionally a different route with or without proposed stops).

The above-described manner of displaying different routes based on estimated mileage of different vehicles for the request guidance (e.g., by automatically considering the mileage of the vehicle when suggesting a route) quickly and efficiently provides an appropriate route for traveling from a first location to a second location, which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to separately determine whether the user vehicle can reach a destination without depleting fuel or electricity), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, in accordance with a determination that the first current estimated travel distance is less than the travel distance of the first proposed route from the first location to the second location (e.g., the first current estimated travel distance of the first vehicle is less than the distance from the first location to the second location (e.g., the distance of the fastest route, the distance of the shortest route, etc., optionally less than a threshold amount, such as 0 miles, 2 miles, 5 miles, 10 miles, 20 miles, 50 miles, etc., or less than 5%, 10%, 15%, 20%, 25%, etc., relative to the remaining fuel or charge), the first proposed route includes a proposed stopping point, such as proposed stopping point 632-1 in fig. 6E (e.g., the first proposed route is selected based on an estimate of the distance the first vehicle is capable of traveling at the current fuel or charge level).

In some embodiments, the first proposed route includes a proposed stopping point to refuel or charge the first vehicle (e.g., at a gas station or an electric vehicle charging station). In some embodiments, if multiple fueling or charging stops are required to reach the second location from the first location, the first proposed route includes multiple proposed stops to fueling or charge the first vehicle. In some embodiments, the second proposed route includes a proposed stopping point to refuel or charge the second vehicle if the second current estimated range of the second vehicle is less than the distance traveled from the first location to the second location. In some embodiments, the proposed parking spot of the second vehicle is different from the proposed parking spot of the first vehicle based on differences in characteristics of the two vehicles (e.g., different fuel types, different mileage, etc.). In some embodiments, the second proposed route of the second vehicle does not include a proposed stopping point.

The above-described manner of including suggested stops in the proposed route provides a quick and efficient way to travel from a first location to a second location (e.g., by automatically considering whether the vehicle should be refueled or charged along the way in order to reach the destination), which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to separately determine whether the user vehicle can reach the destination, and then manually search for refueled or charged stops and add them to the route), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, in accordance with a determination that the first vehicle is associated with the first charging network (e.g., the first vehicle (optionally, the driver of the first vehicle) has a subscription, agreement, or relationship with a network of charging stations, charging station companies, and/or gas station companies, the driver of the first vehicle has a preferred network of charging stations, charging station companies, and/or gas station companies, and/or the first vehicle is limited to a particular network of charging stations (e.g., due to limitations of the first vehicle, such as a compatible vehicle type), the suggested parking spot for increasing the remaining range of the first vehicle is a first parking spot associated with the first charging network, such as in fig. 6L (e.g., the suggested parking spot is within the charging station network, is a charging station company, or is a gas station of a gas station company with which the user has a relationship or preference).

In some embodiments, the association of the first vehicle with a particular charging network is set by a user or provided by a third party application or server, as described below in connection with method 900. Thus, in some embodiments, the device 500 is able to determine charging stations and/or gas stations within a user's network (e.g., the network with which the user or vehicle is associated, the preferred network, or the network required by the first network) and suggest these particular stations. In some embodiments, determining a charging station and/or a gas station within the user network includes receiving information of the charging network and/or the gas station from a source external to the map application, as described below in connection with method 900. In some embodiments, in accordance with a determination that the first vehicle is associated with a second charging network that is different from the first charging network, the proposed parking spot is a second parking spot that is different from the first parking spot associated with the second charging network.

The above-described manner of displaying suggested parking spots within a particular charging network (e.g., by automatically considering a charging network that a user prefers or is otherwise associated with a vehicle when determining charging stations to add to a suggested route) quickly and efficiently provides appropriate charging stations along a route from a first location to a second location, which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to separately determine whether the suggested charging station is within the user's charging network), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the first characteristic of the first vehicle includes a first current estimated range of the first vehicle, such as in fig. 6E (e.g., the first characteristic is an estimate of the distance the first vehicle can travel at a current fuel or charge level). In some embodiments, the estimated value of the distance that the first vehicle can travel depends on the current fuel or power level, the vehicle's travel efficiency, the first vehicle's most recent travel pattern, and/or the driver's habits, etc.

In some embodiments, the first proposed route is based on a first current estimated range, such as in fig. 6E (e.g., the first proposed route is selected based on an estimate of the distance the first vehicle can travel at a current fuel or charge level). In some embodiments, the first proposed route includes a proposed stopping point to refuel or charge the vehicle (e.g., at a gas station or an electric vehicle charging station) if the first current estimated range is insufficient to cause the first vehicle to reach the second location from the first location.

In some embodiments, in response to user input, in accordance with a determination that the third vehicle (e.g., no vehicle option) is a currently selected vehicle to which directions are displayed in the map user interface, the electronic device displays a third proposed route in the map user interface from the first location to the second location that is not based on the current estimated range of the vehicle, such as proposed route 620-1 and proposed route 620-2 in fig. 6B when no vehicle is selected (e.g., a vehicle to which a customized route is not selected).

In some embodiments, the map application includes a list of vehicles that have been registered with the map application from which the user can select a vehicle to determine the guideline. In some embodiments, the list of vehicles includes an "other vehicles" option that is not associated with a particular vehicle (or optionally, an option to disable the customized route) that causes the device to provide a general route (e.g., not customized for a particular vehicle and not taking into account characteristics of a particular vehicle). In some embodiments, if the user selects the "other vehicle" option to disable the customized route based on the characteristics of the particular vehicle, or if the user otherwise disables the customized route (e.g., via a setting), the customized estimated range is not available. Thus, if a particular vehicle is not selected or if a custom route is disabled, the current estimated range information is not available (e.g., because it is not associated with the particular vehicle), and a third proposed route is selected without consideration of the range of the particular vehicle (e.g., without consideration of the current estimated range of the first vehicle or the current estimated range of the second vehicle). In some embodiments, the third proposed route does not automatically include any fueling or charging stopping points. In some implementations, the third proposed route is a fastest route from the first location to the second location. In some embodiments, the third proposed route is a shortest route from the first location to the second location. In some embodiments, the third proposed route is the same as the first proposed route and/or the second proposed route (e.g., if the first current estimated range is greater than sufficient to reach the second location from the first location). In some embodiments, the third proposed route is different from the first proposed route and/or the second proposed route (e.g., if the first current estimated range is insufficient to reach the second location from the first location). In some implementations, if the current range information is not available to the second vehicle (e.g., because the map application is unable to communicate with an external source providing the information), a second proposed route is selected without regard to the range of the second vehicle (e.g., similar to the third proposed route described herein for a general vehicle), optionally with an indication that the proposed route is not customized for the second vehicle.

The foregoing manner of displaying a route based on vehicle characteristics or general routes without selecting a vehicle provides an option to select between custom routes or general routes quickly and efficiently (e.g., by providing custom routes if vehicle information is available and general routes if vehicle information is not available), which simplifies interactions between a user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to always select a particular vehicle or to add a vehicle to an application before requesting guidance), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, displaying the first proposed route from the first location to the second location includes displaying an estimated total travel time of the first proposed route, such as the indications of 59 minutes and 1 hour 4 minutes in fig. 6E (e.g., the first proposed route is displayed with an indication of an estimated length of time to travel along the first proposed route to reach the second location from the first location).

In some embodiments, in accordance with a determination that the first proposed route includes a proposed stopping point for increasing the remaining range of the first vehicle, estimating the total travel time includes increasing an estimated time of the remaining range of the first vehicle at the proposed stopping point, such as in fig. 6E (e.g., if the first proposed route includes a proposed stopping point to refuel or charge the vehicle, the displayed estimated travel time period includes an estimated time period required to refuel or charge the vehicle). For example, if the time period taken to charge the vehicle to the corresponding recommended amount is estimated to be 15 minutes, the estimated total travel time includes a charging time of 15 minutes. In some embodiments, if the second proposed route (e.g., for the second vehicle) includes a proposed stopping point to refuel or charge the second vehicle, the estimated total travel time includes an estimated time for refuel or charge.

The above-described manner of displaying an estimated travel time including fueling and/or charging time provides a more accurate estimate of the length of time required to reach the destination (e.g., by automatically considering the length of time required to fueling or charge the vehicle at a proposed fueling or charging station), which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to separately determine how long it will take to fueling or charging and add it to the estimated duration or estimated arrival time), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the electronic device displays, via the display generating component, one or more representations of one or more road segments associated with the first proposed route, such as in fig. 6F (e.g., when a stepwise guidance of the first proposed route is displayed on the user interface (e.g., optionally in response to user input selecting the first proposed route or user input requesting a stepwise guidance of the first proposed route)), wherein the respective representations of the respective road segments include an indication of an estimated state of the first characteristic of the first vehicle during the respective road segments, such as indication 638-1, indication 638-2, and indication 638-3 in fig. 6F (e.g., when the respective vehicle reaches the respective stepwise guidance or when the vehicle follows the respective stepwise guidance, some or all of the stepwise guidance of the first proposed route is displayed with an indication of an estimated fuel amount or charge level of the respective vehicle).

In some embodiments, the estimated fuel or charge level is displayed for steps not yet followed by the first vehicle (e.g., for future steps). In some embodiments, the estimated fuel or charge level is not displayed for steps already performed by the first vehicle. In some embodiments, the actual fuel or charge level is displayed for the step that the first vehicle has performed. For example, the "start" step (e.g., the first step) and/or the "arrive" step (e.g., the last step) include an indication of an estimated level of charge when the vehicle begins to travel along the proposed route and an estimated level of charge when the vehicle arrives at the destination, respectively. In some embodiments, if the first proposed route includes a proposed stopping point to charge or refuel the vehicle, the proposed stopping point includes an indication of an estimated fuel or charge level when the vehicle reaches the proposed stopping point. In some embodiments, the estimated fuel or charge level may be displayed for other steps. In some embodiments, the estimated fuel or charge level is the estimated fuel or charge level at any time (e.g., along a route corresponding to the step) when the user reaches the beginning of the step, when the user completes the step, or when the first vehicle follows the step. In some embodiments, the estimated charge or fuel level is updated based on new or updated information of the current charge or fuel level of the first vehicle as the first vehicle travels along the proposed route.

The manner in which the above-described display of the estimated values of the fuel or charge level at the respective steps of the proposed route provides the user with information about the fuel or charge level, which simplifies interaction between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., allows the user to use the provided estimated values to determine whether to select the proposed route, select another route, or modify the proposed route), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, when the first vehicle is the currently selected vehicle and when a first proposed route from the first location to the second location is displayed, the electronic device receives user input corresponding to a request to select the second vehicle as the currently selected vehicle via one or more input devices, such as in fig. 6I (e.g., receives input to switch to the second vehicle when the proposed route of the first vehicle is displayed).

In some embodiments, when the first proposed route is displayed, optionally other proposed routes are also displayed. In some embodiments, the first proposed route is a proposed route, while the other proposed routes are alternative routes and are optionally displayed weakly (e.g., darker color, different color, with an indication that is not the most proposed route, is an alternative route, etc.) compared to the first proposed route. In some embodiments, the second proposed route (e.g., the route that would be displayed for the second vehicle when the second vehicle is selected) is one of the other proposed routes displayed.

In some embodiments, in response to receiving a user input corresponding to a request to select a second vehicle as the currently selected vehicle, the electronic device displays a second proposed route in a map user interface, such as in fig. 6J (e.g., switches from displaying the first proposed route to displaying the second proposed route).

In some embodiments, the second proposed route is displayed because the second proposed route is a recommended route of the second vehicle based on characteristics of the second vehicle. In some embodiments, the display of the first proposed route is stopped. In some implementations, the first proposed route remains displayed, but an indication is displayed that it is not the most recommended route (e.g., text is displayed that indicates that the first proposed route is an alternative route, or is displayed in a weakened color compared to the second proposed route and/or compared to the color of the first proposed route prior to receiving input, etc.). In some embodiments, upon receiving the input, the second proposed route is displayed simultaneously with the first proposed route, but with an indication that it is not the most proposed route, and in response to the user input, the second proposed route is updated to indicate that the second proposed route is now the most proposed route (e.g., no text is displayed that indicates that the second proposed route is an alternative route, no text is displayed in a weakened color, a text is displayed that indicates that it is the fastest route, a highlighted color display, etc.).

The above-described manner of the user switching from suggesting a first route to suggesting a second route when switching from selecting a first vehicle to selecting a second vehicle (e.g., by automatically considering characteristics of the second vehicle and switching to a suggested route based on characteristics of the second vehicle instead of a route based on characteristics of the first vehicle) simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to clear search results and perform queries again in order to view a route tailored to the second vehicle), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, when navigating along the first proposed route (e.g., when the device is in a navigation mode associated with the first proposed route in which a user is provided with turn-by-turn navigation instructions), the electronic device determines that the device has reached a proposed stopping point for increasing the remaining range of the first vehicle, such as in fig. 6P (e.g., the device and/or the first vehicle has reached a proposed stopping point location and/or has reached a threshold distance of the proposed stopping point location (e.g., within 30 feet, 50 feet, 200 feet, 500 feet, 2000 feet, etc.)). In some embodiments, the first vehicle is an electric vehicle and the proposed parking spot is a charging station for charging the electric vehicle.

In some embodiments, in response to determining that the device has reached the proposed parking spot to increase the remaining range of the first vehicle, the electronic device displays an indication of the first type of accessory, such as instruction 644 in fig. 6P (e.g., displaying an indication of the type of adapter needed to charge the first vehicle at a charging station associated with the proposed parking spot), via the display generating component in accordance with a determination that the first type of accessory is needed to increase the remaining range of the first vehicle.

For example, it is recommended that the charging station at the parking spot be configured with one or more different outlet or plug types compatible with one or more charger plugs. In some embodiments, if a second type of accessory (e.g., a second type of adapter) is required to be able to use the charging station, an indication of the second type of accessory is displayed. In some embodiments, if the first vehicle is equipped with a compatible charger plug, the first vehicle is able to use the charging station without using the adapter, and thus does not display an indication of the adapter. In some embodiments, if the first vehicle is not equipped with a compatible charger plug, but provides an adapter that can be used to convert an incompatible charger plug to a compatible charger plug, an indication of the adapter is displayed, indicating that the adapter is needed to use the charging station. In some embodiments, the device provides only adapters that the user has previously obtained an indication that the user is in possession of.

The above-described manner of displaying accessories needed to use a charging station quickly and efficiently provides information to a user how to connect to the charging station (e.g., by automatically considering the requirements of the charging station, the type of plug installed on the vehicle, and the available adapters), which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to separately determine whether the adapter is needed or whether the user vehicle is actually able to use the charging station), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the electronic device determines that the device has reached a proposed parking spot for increasing the remaining range of the first vehicle when navigating along the first proposed route, such as in fig. 6P (e.g., the device and/or the first vehicle has reached the proposed parking spot location and/or within a threshold distance of the proposed parking spot location (e.g., within 30 feet, 50 feet, 200 feet, 500 feet, 2000 feet, etc.)).

In some embodiments, in response to determining that the device has reached the proposed parking spot to increase the effective range of the first vehicle, the electronic device displays a first affordance via the display generation component to pause navigation along the first proposed route, such as button 662 in fig. 6Q (e.g., a button to display pause navigation mode).

In some embodiments, while displaying the first affordance to pause navigation, the electronic device receives user input via one or more input devices selecting the first affordance, such as in fig. 6Q (e.g., tap input on a button).

In some embodiments, in response to receiving user input selecting the first affordance, the electronic device displays, via the display generation component, a second affordance to resume navigation along the first suggested route (e.g., a button to resume navigation mode) and an indication of the first characteristic of the first vehicle while the first characteristic is increasing, such as notification 668 in fig. 6R or indication 672 in fig. 6T (e.g., display of a current charge level, a current estimated range, and/or a remaining length of time to charge the first vehicle to reach the suggested charge level).

In some implementations, the button to resume navigation mode replaces the button to pause navigation mode. In some embodiments, the button to pause the navigation mode changes to a button to resume the navigation mode. In some implementations, selectable options are displayed on the map user interface for resuming navigation along the first proposed route when no guidance or route is displayed. In some embodiments, the device displays a notification that is selectable to display the map application and optionally resume navigation along the first proposed route.

In some embodiments, the indication is dynamically updated as update information regarding the first characteristic is received. In some implementations, the map application continuously (e.g., at a predetermined frequency, such as once every 0.25 seconds, every 0.5 seconds, every 1 second, every 3 seconds, every 5 seconds, etc.) polls a third party application or source (e.g., as described below in connection with method 900) to receive updated information of the first characteristic.

The manner in which the first characteristic is monitored as the first vehicle is refueled or charged provides the user with updates regarding the refueled or charged status quickly and efficiently (e.g., by automatically displaying updated fuel and charge information even though the user has paused active navigation), which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to navigate to a separate user interface to determine the current status of viewing the fuel or charge level), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to use the electronic device faster and more efficiently while reducing errors in device usage.

In some embodiments, the electronic device determines that the current estimated range of the first vehicle is less than the remaining travel distance of the first proposed route from the current location to the second location when navigating along the first proposed route, such as in fig. 6V (e.g., when in navigation mode and traveling along the first proposed route, receives updated information about the first vehicle and determines that the first vehicle will not reach the destination from the current location of the first vehicle based on the updated information).

In some embodiments, the received updated information is an updated estimated range or an updated current power or fuel level. For example, if the first vehicle did not charge or refuel to a recommended level at a previous recommended stop point, or if the first vehicle took a different route than the recommended route, the estimated range may be insufficient for the first vehicle to reach the destination and the device will recommend a stop point to refuel or charge the first vehicle. In some implementations, the update information is received from a source external to the map application, as described below in connection with method 900.

In some embodiments, in response to determining that the current estimated range of the first vehicle is less than the remaining travel distance of the first proposed route from the current location to the second location, the electronic device updates the first proposed route to include a proposed stopping point for increasing the remaining range of the first vehicle, such as in fig. 6V (e.g., if the updated estimated range indicates that the first vehicle does not have sufficient fuel or charge to the destination (or arrives at the destination with less than a threshold amount of fuel or charge, such as with less than 5%, 10%, 15%, 20%, etc., remaining fuel or charge, or with less than 2 miles, 5 miles, 10 miles, 20 miles, 50 miles, etc.), then one proposed stopping point is added to the route to refuel or charge the first vehicle.

Thus, in some embodiments, while in navigation mode or while the vehicle is traveling toward the destination, the device can dynamically add suggested parking points to refuel or charge without requiring the user to perform additional queries for the route from the current location of the vehicle to the destination to determine where to refuel or charge the vehicle.

The above-described approach of suggesting a stopping point to refuel or charge a vehicle while navigating along a route provides a user with suggested stopping points quickly and efficiently in the event that a stopping point is now needed to reach a destination (e.g., by automatically determining an estimated range such that a first vehicle will not reach a destination and suggesting a stopping point to refuel or charge), which simplifies interaction between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to separately monitor fuel or charge levels and separately determine whether the vehicle will reach a destination, and then manually add a refuel or charge stopping point to the route), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the first characteristic of the first vehicle is associated with a first travel limit of the first vehicle, such as in fig. 6CC (e.g., a geographic area (e.g., city, county, district, etc.) has implemented applying a travel limit of certain vehicle sets based on the characteristics of the respective vehicles). In some embodiments, the travel limit may be implemented based on the license plate of the vehicle. For example, during certain periods of time, an odd-numbered vehicle (e.g., a vehicle with an odd license plate tail number) is not allowed to travel in the restricted area, but an even-numbered vehicle (e.g., a vehicle with an even license plate tail number) is allowed to travel in the restricted area. In some embodiments, limitations based on other characteristics are also possible, such as the type of vehicle (e.g., whether the vehicle is a passenger car, a commercial car, a truck, an SUV, a semi-trailer truck, whether the vehicle is above a certain height, whether the vehicle is above a certain total weight, etc.).

In some embodiments, the first proposed route is based on a first travel limit, such as in fig. 6CC (e.g., the proposed route is based on whether the first vehicle is subject to a travel limit). For example, if the travel limit is one that does not allow an even number of cars to travel in the restricted area and the normally recommended route (e.g., the fastest route) will cause the cars to pass through the restricted area, then the normally recommended route is not recommended, but a route that avoids the limit (e.g., a route around the restricted area) is recommended to the user. In some embodiments, the normally suggested route is also displayed to the user at the same time, but with an indication that it is affected by the restriction. In some implementations, if the restrictions apply only during certain time windows, the proposed route is only affected during those time windows (e.g., if the current time is outside of the time window in which the restrictions apply, the proposed route is selected without consideration of the restrictions).

In some embodiments, the second characteristic of the second vehicle is associated with a second travel limit of the second vehicle that is different than the first travel limit, such as in fig. 6FF (e.g., the second vehicle has a different characteristic than the first vehicle and is therefore restricted to travel in the restricted area or not restricted to travel in the restricted area).

In some embodiments, the second proposed route is based on a second travel limit, such as in fig. 6FF (the proposed route of the second vehicle is based on whether the second vehicle is affected by the travel limit).

In some embodiments, the travel limit applied to the second vehicle is the same travel limit as that applied to the first vehicle, and the apparatus is able to determine whether the first vehicle or the second vehicle is prohibited from traveling the specific route due to the travel limit. In some embodiments, the travel limit applied to the second vehicle is a different travel limit than the travel limit applied to the first vehicle, and the apparatus is capable of determining whether the second vehicle is capable of traveling the particular route based on affecting the travel limit of the second vehicle. In some embodiments, the proposed route of the second vehicle is the same as the proposed route of the first vehicle, as the second vehicle and the first vehicle are similarly affected by the travel limit (e.g., both are even numbered automobiles). In some embodiments, the proposed route of the second vehicle is different from the proposed route of the first vehicle because the restriction affects the vehicles differently. In some embodiments, if the second vehicle is not affected by the restriction (e.g., allowed to travel in a restricted area), the selection of the proposed route does not take into account the restriction (e.g., is the fastest route and/or the shortest route, etc.). In some embodiments, the second vehicle is affected by the same restriction as the restriction affecting the first vehicle and another restriction different from the restriction affecting the first vehicle, and the selection of the proposed route avoids both restrictions. In some embodiments, the impact of whether the vehicle is restricted is based on a characteristic of the vehicle, such as license plate style or vehicle type. In some embodiments, a set of different restrictions applies to different types of vehicles (e.g., a first set of restrictions applies to passenger vehicles, and a second set of restrictions applies to commercial vehicles, etc.). In some implementations, the map application receives information about the vehicle characteristics from a source external to the map application, as described below in connection with method 900. In some implementations, the user provides license plate information to the map application similar to the process of adding vehicles to the map application as described below in connection with method 900.

The manner in which the different routes are displayed based on whether the respective vehicle is affected by the travel restriction provides for appropriate routes to travel from the first location to the second location quickly and efficiently (e.g., by automatically considering restrictions applied to the respective vehicle), which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to separately determine whether to prohibit the user from traveling in the restricted area), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some implementations, the first travel limit is determined using anonymous characteristics corresponding to first characteristics of the first vehicle (e.g., characteristics of the vehicle are anonymously processed when determining a proposed route of the vehicle).

In some embodiments, a third party server or third party service is used to collect travel information or road conditions. For example, servers hosted by government agencies provide current traffic flow information, current faults, feasible routes, and/or restriction information. In some embodiments, the server maintains travel limit information and can be queried to determine whether to prohibit certain vehicles from traveling in the restricted area. In some embodiments, the server is queried by providing vehicle license plate information and an intended route, and the server provides a determination as to whether to prohibit the vehicle from traveling along a portion or all of the intended route. In some embodiments, because the travel limit is based on the pattern of the license plate (e.g., whether the license plate tail number is even or odd) rather than the full license plate number, the device is able to anonymously process the license plate to protect user privacy and thus prevent information about the user's travel habits or history from being sent from the device to another entity and/or from another entity to the device. For example, the device provides a randomly generated license plate number (optionally along the license plate pattern of the area) to the server, the tail number of the license plate number being a randomly generated even or odd number (based on whether the first vehicle is even or odd) to simulate the license plate pattern of the first vehicle, while not providing actual license plate information of the first vehicle. Thus, in some embodiments, the device uses anonymous characteristics of the same type of characteristics as the first characteristics (e.g., optionally characteristics related to respective travel limits).

The above-described manner of using anonymous characteristics of vehicles to determine suggested routes quickly and efficiently determines appropriate routes for respective vehicles while preserving user privacy (e.g., by automatically removing identifying information when determining a route to be suggested), which simplifies interactions between a user and an electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., by allowing a user to enter real details of a vehicle and not requiring the user to provide incorrect identifying information, which may result in incorrectly determining whether a user vehicle is restricted, such as in the case of a change in restriction), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the first characteristic of the first vehicle is associated with a first travel limit of the first vehicle, such as in fig. 6CC (e.g., the first characteristic of the first vehicle is related to a travel limit of the restricted area and the first vehicle is prohibited or not prohibited from traveling in the restricted area). In some embodiments, the license plate pattern of the first vehicle matches the restriction pattern such that the first vehicle is restricted or unrestricted.

In some embodiments, the first proposed route is based on a first travel limit, such as in fig. 6CC (e.g., the first proposed route provided to the user is selected for the first vehicle based on whether the first vehicle is prohibited from traveling in the restricted area). In some embodiments, if the first vehicle is disabled, the first proposed route is a route that avoids the restriction (e.g., bypasses the restricted area). In some embodiments, if the first vehicle is not disabled, the first proposed route is selected without consideration of the restriction (e.g., is the fastest route or the shortest route, etc.).

In some embodiments, in response to user input, in accordance with a determination that a vehicle to which guidance is not currently selected in the map user interface is displayed, the electronic device displays a third proposed route in the map user interface from the first location to the second location that is not based on a travel limit, such as in fig. 6X (e.g., a vehicle to which a customized route is not selected).

In some embodiments, the map application includes a list of vehicles that have been registered with the map application from which the user can select a vehicle to determine the guideline. In some embodiments, the list of vehicles includes an "other vehicles" option that is not associated with a particular vehicle (or optionally, an option to disable the customized route) that causes the device to provide a general route (e.g., not customized for a particular vehicle and not taking into account characteristics of a particular vehicle). In some embodiments, if the user selects the "other vehicle" option to disable the customized route based on the characteristics of the particular vehicle, or if the user otherwise disables the customized route (e.g., via a setting), the customized estimated range is not available. Thus, if a particular vehicle is not selected or if a custom route is disabled, then the current license plate information is not available (e.g., because it is not associated with the particular vehicle) and a third proposed route is selected without regard to the travel limit of the particular vehicle (e.g., without regard to the current travel limit of the first vehicle or the travel limit of the second vehicle). In some embodiments, the third proposed route travels through a restricted area. In some implementations, the third proposed route is a fastest route from the first location to the second location. In some embodiments, the third proposed route is a shortest route from the first location to the second location. In some embodiments, the third proposed route is the same as the first proposed route and/or the second proposed route (e.g., if the first vehicle is not prohibited from traveling in the restricted area). In some embodiments, the third proposed route is different from the first proposed route and/or the second proposed route (e.g., if the first vehicle and/or the second vehicle is prohibited from traveling in the restricted area). In some embodiments, if the travel limit information is not available to the second vehicle (e.g., because the map application cannot communicate with an external source providing the information), the second proposed route is selected without regard to the travel limit that may be applied to the second vehicle (e.g., similar to the third proposed route described herein for a general vehicle, optionally with an indication that the proposed route is not customized for the second vehicle).

The above-described manner of displaying one route based on whether a particular vehicle is restricted or displaying a general route based on whether a particular vehicle is restricted provides an option to select between custom routes or general routes quickly and efficiently (e.g., by providing custom routes if car information is available, but general routes if car information is not available), which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to always select a particular vehicle or to add vehicles to the application before requesting guidance), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, in accordance with a determination that the third proposed route passes through the area limited by the respective travel limit, the electronic device displays, via the display generating component, an indication that the third proposed route passes through the area limited by the travel limit, such as in fig. 6X (e.g., if no vehicle is selected, the displayed proposed route is displayed regardless of whether the particular vehicle is affected by the limited area).

In some embodiments, if the third proposed route passes through or would otherwise be affected by the restricted area, an indication is displayed that the proposed route is affected by the restricted area to inform the user that restrictions may be applied to the user vehicle. In some embodiments, the indication is a text indicator that a restriction is applied. In some embodiments, the indication is an icon representing that the restriction is applied. In some implementations, the icon is displayed at or near a location of a portion of the proposed route that enters the restricted area. In some embodiments, icons are displayed on respective ones of the suggested routes in the list of suggested routes (which are optionally displayed in response to a request for guidance) to indicate that the suggested routes are affected by the travel limit. In some embodiments, 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 an icon representing the type of restriction).

The manner of displaying an indication in the event that a route is affected by a travel limit (e.g., when the route is a general route that is not tailored to a particular vehicle) described above quickly and efficiently provides an indication to the user that the user's vehicle may be subject to a travel limit (e.g., by displaying an indication that a travel limit is applied when the user does not select a particular vehicle to search for its route), which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to always select a particular vehicle or to add a vehicle to an application before requesting directions to receive information regarding a travel limit), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, in accordance with a determination that a given route from a first location to a second location is associated with a travel limit (e.g., if the proposed route travels through a limited area and is thus affected by the travel limit), in accordance with a determination that one or more conditions are met (e.g., an automobile has not yet been added to the map application), the electronic device displays, via the display generating component, an affordance for adding information about the respective vehicle to the map user interface, such as button 688 in fig. 6W (e.g., a display notification, an element on the user interface, and/or a link or button that is selectable to initiate a process of adding vehicle information to the map application).

In some implementations, a notification is displayed on a lock screen, a wake screen, or a notification user interface indicating that license plate information may be added to the map application. In some implementations, a banner or other user interface element is displayed in the map application indicating that license plate information may be added to the map application. In some embodiments, an affordance for adding information about the respective vehicle is not displayed if one or more conditions are not met.

In some embodiments, the electronic device receives user input (e.g., tap input or any other selection input regarding the affordance) selecting the affordance via one or more input devices. In some implementations, in response to receiving the user input, the electronic device initiates a process of adding information about the respective vehicle to the map user interface (e.g., initiating a process of the user adding license plate information to the map application (e.g., information associated with the travel limits)).

In some embodiments, the process includes displaying a guide or step-by-step instructions to guide the user in adding license plate information. In some embodiments, the map application maintains a list of vehicles associated with the user, optionally including license plate information and/or other characteristics of the respective vehicle. In some embodiments, the characteristics of the vehicle are automatically populated with information received from an external source, as described below in connection with method 900.

The manner of adding vehicle information described above (e.g., providing an affordance selectable to initiate a process of adding vehicle information to a map application) provides a user with the ability to quickly and efficiently provide the map application with vehicle information related to travel limits, which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient, which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, when navigating along the first proposed route, the electronic device determines that the current location of the device satisfies one or more conditions associated with the travel limit of the first proposed route, such as in fig. 6DD (e.g., when in navigation mode and traveling along the proposed route, determining that the user is about to enter the restricted area (optionally only when the currently selected vehicle is prohibited from traveling in the restricted area or when no vehicle is currently selected)).

In some embodiments, the proposed route includes directions that guide the user into the restricted area. In some implementations, a suggested route along which the user is traveling is provided because the user does not select a particular car to provide the route or because the user chooses to navigate using a route that travels into a restricted area.

In some embodiments, in response to determining that the current guidance satisfies one or more conditions associated with the travel limit, the electronic device displays an indication of the travel limit via the display generation component, such as in fig. 6DD (e.g., within a threshold distance (e.g., 10 feet, 50 feet, 100 feet, 300 feet, 500 feet, 1000 feet, etc.) of entering the restricted area, displaying an indication that the user is about to enter the restricted area).

In some embodiments, the indication is a text indication that a restricted area is upcoming. In some implementations, the indication is an icon in the user interface at or near a location corresponding to the restricted area. In some embodiments, 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 an icon representing the type of restriction).

The above-described manner of displaying an indication that a user is about to enter a restricted area provides a visual indication to the user that the user may be prohibited from traveling in the restricted area quickly and efficiently, which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to separately determine where the boundary of the restricted area is and to limit whether to apply to a vehicle currently selected by the user), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to use the electronic device more quickly and efficiently while reducing errors in device usage.

It should be understood that the particular order in which the operations in fig. 7 are described is merely exemplary and is not intended to suggest that the described order is the only order in which the operations may be performed. Those of ordinary skill in the art will recognize a variety of ways to reorder the operations described herein. Additionally, it should be noted that the details of other processes described herein in connection with other methods described herein (e.g., methods 900, 1100, and 1300) are likewise applicable in a similar manner to method 700 described above in connection with fig. 7. For example, the operations of the electronic device displaying a customized navigation route described above with reference to method 700 optionally have one or more of the characteristics described herein with reference to other methods described herein (e.g., methods 900, 1100, and 1300) of receiving information about respective vehicle characteristics, anonymously processing vehicle identifiers, valid route determination, and the like. For the sake of brevity, these details are not repeated here.

The operations in the above-described information processing method are optionally implemented by running one or more functional modules in an information processing apparatus such as a general-purpose processor (e.g., as described with respect to fig. 1A-1B, 3, 5A-5B) or a dedicated chip. Furthermore, the operations described above with reference to fig. 7 are optionally implemented by the components depicted in fig. 1A-1B. For example, display operations 702, 708, and 710, and receive operation 704 are optionally implemented by event sorter 170, event recognizer 180, and event handler 190. An event monitor 171 in the event sorter 170 detects a contact on the touch-sensitive surface 604 and an event dispatcher module 174 delivers event information to the application 136-1. The respective event identifier 180 of the application 136-1 compares the event information to the respective event definition 186 and determines whether the first contact at the first location on the touch-sensitive surface corresponds to a predefined event or sub-event, such as a selection of an object on the user interface. When a respective predefined event or sub-event is detected, the event recognizer 180 activates an event handler 190 associated with the detection of the event or sub-event. Event handler 190 optionally utilizes or invokes data updater 176 or object updater 177 to update the application internal state 192. In some embodiments, event handler 190 accesses a corresponding GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one of ordinary skill in the art how other processes may be implemented based on the components depicted in fig. 1A-1B.

Receiving information about a corresponding vehicle characteristic

Users interact with electronic devices in many different ways, including using electronic devices to view and find geographic locations on a map. In some embodiments, a user may request directions from one geographic location to another. In some embodiments, suggested directions between locations provided to a user in response to a user request may be customized based on characteristics of the user's vehicle. The embodiments described below provide a means for receiving information regarding the characteristics of a user's vehicle and using the received information to provide a customized route. Receiving this information and customizing the route enhances user interaction with the electronic device and shortens the duration required for the user to perform the operation. Shortening the operating time reduces the power usage of the device and extends the battery life of the battery-powered device.

Fig. 8A-8 CC illustrate an exemplary manner in which an electronic device receives information regarding corresponding vehicle characteristics according to some embodiments of the present disclosure. The embodiments in these figures are used to illustrate the processes described below, including the processes described with reference to fig. 9. Although fig. 8A-8 CC illustrate various examples of the manner in which an electronic device may be able to perform the processes described below with reference to fig. 9, it should be understood that these examples are not meant to be limiting and that the electronic device may be able to perform one or more of the processes described below with reference to fig. 9 in a manner that is not explicitly described with reference to fig. 8A-8 CC.

Fig. 8A illustrates an electronic device 500 displaying a user interface 800 (e.g., via a display device, via a display generation component, etc.). In some implementations, the user interface 800 is displayed via a display generation component. In some embodiments, the display generation component is a hardware component (e.g., including electronic components) capable of receiving display data and displaying a user interface. In some embodiments, examples of display generating components 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 in communication with device 500.

In some implementations, the 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 locations, and/or request directions from one location to another, similar to the map application described above in connection with fig. 6A). In some implementations, the map application is an application installed on the device 500.

In some implementations, the user interface 800 includes a representation of a map having a current location of the electronic device. In fig. 8A, the user interface 800 does not include any suggested route or travel guidance, and is optionally a default user interface of the map application (e.g., while in a browsing state) that includes a location indicator 804. In fig. 8A, the user interface 800 includes a settings option 802 that is selectable to display the settings user interface. In some implementations, the user interface 800 includes a location indicator 804 that represents the current location of the device 500 on a representation on a map. In some implementations, the device 500 displays a user interface 806. In some implementations, the user interface 806 includes a search field 808 for performing a search for a location or business. In some implementations, the user interface 806 includes one or more shortcuts 810 that are selectable to search for and display respective locations associated with respective shortcuts. For example, a "home" shortcut is selectable to display a location associated with "home", a "workplace" shortcut is selectable to display a location associated with "workplace", and a "fitness facility" shortcut is selectable to display a location associated with "fitness facility".

In fig. 8A, device 500 determines that an application associated with vehicle 1 (e.g., a vehicle 1 application) is not currently installed on the device. In some embodiments, the application associated with the vehicle 1 is an application external to the map application (e.g., a third party application, an application provided by the manufacturer of the vehicle 1, etc.). In some embodiments, the application associated with the vehicle 1 is configured to receive and/or display information associated with the vehicle 1. For example, the application can receive information about one or more characteristics of the vehicle 1 from a computer on the vehicle 1 or from a server (which in turn receives information from a computer on the vehicle 1). For example, the application can receive a current fuel and/or charge level of the vehicle and/or can receive estimated range information of the vehicle (or determine an estimated range based on the current fuel and/or charge level). In some embodiments, the application is capable of receiving and/or maintaining information about other characteristics of the vehicle, such as make, model, color, vehicle size, climate control status, door open or closed status, current tire pressure, air bag status, exhaust system status, and the like. In some embodiments, the map application is capable of receiving information from an application associated with the vehicle 1. In some embodiments, the map application receives information about the vehicle 1 for providing a customized route while traveling using the vehicle 1, similar to that described above in connection with method 700. In some implementations, the map application may receive information about the vehicle 1 from other sources. For example, the user may manually provide information to the map application (e.g., manual input from the user), which may embed a QR code (e.g., information about the vehicle itself, or information about how to communicate with a server or system to receive information about the vehicle), an API call from the map application (e.g., through the map application, through the device 500, etc.) to a computer system (e.g., a computer system associated with the vehicle 1), or other means by which the user actively selects to share his vehicle information with the map application.

In fig. 8A, because the device 500 determines that no application associated with a particular vehicle is installed on the device, the user interface 800 does not include an indication and/or button to link the application associated with the vehicle with the map application. In some implementations, the device 500 provides a way for a user to manually enter information to associate a vehicle with a map application. In some implementations, the device 500 provides a way for a user to specify information about a vehicle (e.g., vehicle manufacturer, vehicle VIN, or other identifying information) so that a map application communicates with a computer system (e.g., a computer system associated with the vehicle) to obtain vehicle data.

In fig. 8B, the map application and/or the device 500 has determined that a vehicle 1 application (e.g., an application associated with the vehicle 1) is installed on the device 500. In some embodiments, in accordance with a determination that a vehicle 1 application is installed on device 500, user interface 806 includes an indication 812. In some embodiments, the indication 812 includes a description of connecting the vehicle 1 application with the map application to obtain the customized route and/or charging recommendation. Additionally or alternatively, the user interface 806 includes an indication that the user can enter information about their particular vehicle in order to manually link the map application to the vehicle or access a computer system of the particular vehicle (e.g., through an API) to complete the linking process. In some embodiments, the indication 812 includes a button 814 that is selectable to initiate a process of linking the map application with the vehicle 1 application. In the embodiment shown in fig. 8B, the vehicle 1 is an electric vehicle. In some embodiments, indication 812 is displayed only when the map application has not been linked with the vehicle 1 application. In some embodiments, indication 812 is displayed only if the vehicle 1 application itself is configured to provide information about vehicle 1 (e.g., the vehicle 1 application has been linked with vehicle 1 and is capable of receiving and providing information about vehicle 1). For example, if the vehicle 1 application is already installed on the device 500, but has not yet been launched or linked to the vehicle 1 such that the vehicle 1 application receives data about the vehicle 1, the indication 812 is optionally not displayed until the vehicle 1 application is launched and/or linked to the vehicle 1. In some embodiments, indication 812 is displayed even though the user has manually added vehicle 1 to the map application (optionally, initiating a process of linking the vehicle 1 application with the map application will override or supplement the information about vehicle 1 manually provided to the map application by the user).

In some embodiments, the indication 812 may be displayed in accordance with a determination that conditions other than the installed vehicle 1 application are met. For example, as described above, the map application can receive information from one or more external sources (such as an application installed on the same device as the map application), from an external server, from a computer system associated with the vehicle (e.g., an onboard computer system of the vehicle, such as an ECU of the vehicle), and so forth. Thus, in some embodiments, if the device 500 determines that any of these mechanisms for receiving information about the user's vehicle are available, the device 500 may display an indication 812. For example, if the device 500 determines that the device 500 is in communication or capable of communication with an on-board computer system of the user vehicle, the device 500 may display an indication 812 to link the user vehicle with the map application. In such embodiments, in response to the indication 812 of the user selection, the device 500 may initiate a process of adding the user vehicle to the map application (optionally pairing the device 500 with an on-board computer system of the vehicle), as will be described in detail below. In some embodiments, the device 500 may display the indication 812 without satisfying the above conditions. In such embodiments, in response to the indication 812 of the user selection, the user may be presented with one or more options to link the vehicle 1 with the map application (e.g., an option to provide communication details to connect with a server associated with the user vehicle, an option to scan a QR code that provides communication details to connect with a server associated with the user vehicle, etc.). In some embodiments, the map application may access information about the user's vehicle via an API call to another application, a server, an on-board computer system of the vehicle, or the like.

FIG. 8C illustrates an exemplary lock or wake screen user interface 816 that includes a notification 818. In some embodiments, the notification 818 is displayed in accordance with a determination that the vehicle 1 application is installed on the device 500. In some embodiments, notification 818 includes a description of connecting the vehicle 1 application with the map application to obtain the customized route and/or charging recommendation. In some implementations, selection of notification 818 initiates a process of linking the map application with the vehicle 1 application (e.g., displaying the map application, automatically navigating to a user interface for linking the vehicle 1 application with the map application, such as the user interface shown in fig. 8E). In some embodiments, notification 818 is only displayed when the map application has not been linked to the vehicle 1 application.

In some embodiments, notification 818 is displayed on any user interface and is not limited to only locking or waking up a screen user interface. For example, notification 818 may be displayed when device 500 is displaying a system user interface (e.g., home screen user interface, application launch user interface, setup user interface) or a user interface of an application. In some embodiments, notifications 818 may be displayed on a notification user interface (e.g., a user interface that includes one or more activity notifications). In some embodiments, the notification 818 is persistent and remains displayed on the lock or wake screen user interface (optionally displayed on the notification user interface) until the user manually dismisses the notification 818, until the user selects the notification 818, and/or until the user links the vehicle 1 application with the map application.

In fig. 8D, user input 803D selecting button 814 is received. In some embodiments, in response to user input 803d, device 500 initiates a process of linking vehicle 1 (e.g., via a vehicle 1 application) with a map application, as shown in fig. 8E. In fig. 8E, the device 500 displays a user interface 820. In some implementations, the user interface 820 is a user interface for confirming a link of the vehicle 1 (e.g., by the vehicle 1 application) with the map application. In some embodiments, the user interface 820 includes icons 822 (e.g., application icons) representing vehicle 1 applications. In some implementations, the user interface 820 includes a description 824 that describes features that connect the vehicle 1 (e.g., through the vehicle 1 application) with the map application that allow the map application to receive the vehicle 1. In some implementations, the user interface 820 includes a button 826 and a button 828. In some implementations, the button 826 is selectable to connect (e.g., add, link, register, etc.) the vehicle 1 with the map application. In some implementations, the button 828 is selectable to terminate the process of linking the vehicle 1 with the map application (e.g., un-linking).

In fig. 8E, user input 803E selecting button 826 is received. In some embodiments, in response to receiving user input 803e, device 500 displays user interface 830. In some embodiments, the user interface 830 includes a vehicle associated with a vehicle 1 application (e.g., an application displaying the indication 812). For example, a particular vehicle application may be associated with multiple vehicles and receive and provide information about the multiple vehicles (e.g., whether the vehicles have the same make and model, whether the vehicles are manufactured by the same manufacturer, whether the application is compatible with multiple vehicles, whether the application is compatible with different make and/or model vehicles, etc.). In FIG. 8F, user interface 830 includes a list 836-1 corresponding to vehicle 1 and a list 836-2 corresponding to vehicle 2. In such embodiments, the vehicle 1 application is able to access and provide information about the vehicle 1 and the vehicle 2 (e.g., the vehicle 1 and the vehicle 2 are optionally the same brand and/or model, and/or both the vehicle 1 and the vehicle 2 are registered with the vehicle 1 application). As shown in FIG. 8F, list 836-1 includes icon 838-1 representing vehicle 1 and description 840-1. In some embodiments, description 840-1 includes a vehicle name (or optional vehicle make and/or model) and a current state of charge (and optionally a current estimated range) of vehicle 1. Similarly, list 836-2 includes an icon 838-2 representing vehicle 2 and a description 840-2 including the name of vehicle 2 and the current state of charge of vehicle 2 (and optionally the current estimated range). The vehicle name and the current state of charge are optionally received from the vehicle 1 application. In some implementations, each list includes an indication (e.g., indication 842-1 and indication 842-2) that indicates that the respective vehicle is to be added to the map application.

In fig. 8F, user input 803F is received in list 836-2, deselecting vehicle 2 from being added to the map application, as shown in fig. 8G. Thus, only vehicle 1 will be added to the map application (e.g., the map application will receive only information about vehicle 1, and not information about vehicle 2). In fig. 8G, a user input 803G is received selecting an affordance 834 corresponding to confirming addition of vehicle 1. In some embodiments, in response to user input 803g, vehicle 1 is added to the map application and the vehicle 1 application is linked with the map application, as shown in fig. 8H. In some embodiments, linking the vehicle 1 application allows the map application to receive information about the vehicle 1 from a source external to the application. In some embodiments, the information is received from a vehicle 1 application. In some implementations, information is received from a server external to the device 500 (e.g., linking the vehicle 1 application with the map application provides the map application with information of the external server and/or credentials in communication with the external server).

It should be appreciated that the process of providing the indication and button linking the vehicle 1 application with the map application described above may be repeated for multiple applications associated with other vehicles. For example, in the above-described embodiment, the vehicle 1 application is associated with the vehicle 1 and the vehicle 2. In addition to the vehicle 1 application, the device 500 may also install a vehicle 3 application associated with the vehicle 3. In such embodiments, an indication, such as indication 812, may be displayed for linking the vehicle 3 application with the map application (e.g., adding the vehicle 3 to the map application and enabling the map application to receive information about the vehicle 3 from the vehicle 3 application and/or an external source). In other embodiments, the indication 812 is displayed only for one application associated with the vehicle (e.g., only once), and after performing the linking process described above, the user may manually initiate the process for other vehicle applications via a setup user interface of the map application (e.g., such as user interface 848 described below).

In fig. 8H, a user input 803H selecting the setting button 802 is received. In some embodiments, in response to user input 803h, device 500 displays a user interface 848, as shown in fig. 8I. As shown in fig. 8I, the user interface 848 is a settings user interface for altering and/or modifying one or more settings associated with the map application. For example, the user interface 848 includes options 850, 852, 854, 856, 858, and 860 that correspond to different options and/or settings. In some embodiments, option 854 corresponds to the "my vehicle" option and is selectable to display vehicles that have been added to the map application. In fig. 8I, user input 803I is received selecting option 854. In response to user input 803i, device 500 displays a user interface 862, as shown in FIG. 8J. The user interface 862 corresponds to a "my vehicles" user interface in which vehicles that have been registered with, added to, and/or linked to a map application are displayed. As shown in fig. 8J, the user interface 862 includes a list 864 corresponding to vehicles 1 added according to the linking process described above. In some implementations, the user interface 862 includes a list of vehicles that are added to the map application via a process different from the process of linking the map application with an application associated with the vehicle.

In some embodiments, list 864 includes icons representing vehicles, names of the vehicles (e.g., user-selected names, brands, and/or models), and an indication 866 indicating the current power level and/or estimated range of the vehicle.

In fig. 8J, user input 803J of selection list 864 is received. In some embodiments, in response to user input 803j, device 500 displays user interface 868. The user interface 868 corresponds to a setup user interface of the vehicle 1. In fig. 8K, the user interface 868 includes an icon 870 and an edit link 872. In some embodiments, icon 870 is a representation of vehicle 1 and optionally has visual characteristics based on the visual characteristics of vehicle 1. For example, if the vehicle 1 is red, the map application can receive information from an external source (e.g., from the vehicle 1 application) indicating that the vehicle 1 is red, and the icon 870 includes a red car icon (e.g., without the user specifying an icon color). In some embodiments, edit link 872 is selectable to view and/or change the color and/or pattern of vehicle 1 (e.g., avoid automatically populated colors and/or patterns based on received information about vehicle 1), as will be described below.

In some implementations, the user interface 868 includes a name field 874. In some embodiments, the name field 874 is selectable to edit the name of the vehicle 1 (e.g., a soft keyboard that enables a display user to edit and/or provide a desired name). In some embodiments, the name field 874 is pre-populated with names provided by the vehicle 1 application (e.g., brand and/or model number of car, names selected by a user of the vehicle 1 application, etc.). In some implementations, the user interface 868 includes a charger option 876-1 and a charger option 876-2. The charger option 876-1 corresponds to a charging plug type of the vehicle 1 and is selectable to view and/or edit charger types and/or available adapters, as will be described in more detail below. In some embodiments, charger options 876-2 correspond to charging network preferences and/or compatibility with vehicle 1, and are selectable to view and/or edit the charging network to charge vehicle 1, as will be described in detail below.

In some implementations, the user interface 868 includes an application list 878 that corresponds to applications associated with the vehicle 1 (e.g., and linked to a map application). In some implementations, selection of the application list 878 causes an application associated with the vehicle 1 to be displayed. In some embodiments, if vehicle 1 is added via a process other than the application linking process described above (e.g., such as via manually adding a vehicle), user interface 868 does not include application list 878.

In some embodiments, user interface 868 includes manufacturer information 880-1 and model information 880-2 that include information about the make and model of vehicle 1, respectively. In some embodiments, brand and/or model information for the vehicle 1 is received from the vehicle 1 application and, thus, manufacturer information 880-1 and model information 880-2 are automatically populated when the vehicle 1 application is linked to the map application.

In fig. 8L, a user input 803L selecting an edit link 872 is received. In some embodiments, in response to user input 803l, device 500 displays a user interface 882 for viewing and/or editing visual characteristics of vehicle 1. In fig. 8M, the user interface 882 includes a plurality of color options 886-1 through 886-18 that are selectable to set the color of the vehicle 1 (e.g., which serve as colors for icons representing the vehicle 1, such as icon 884 and icon 870). In some embodiments, the color options selected in the user interface 882 are initially automatically populated based on color information received from the vehicle 1 application. For example, the vehicle 1 application can provide information to the map application regarding the visual characteristics of the vehicle 1 and indicate to the map application that the vehicle 1 has a color associated with the color options 886-16. Thus, color options 886-16 are automatically selected. In some embodiments, the user is able to select a different color option from the list of color options and override the color option provided by the vehicle 1 application. In some embodiments, the color options displayed in the user interface 882 are unique color options available for the particular make and model of the color (e.g., the map application receives all available color options from the vehicle 1 application). In some embodiments, the displayed color options are generally available vehicle colors and are not selected for display based on the available colors of the particular vehicle.

In FIG. 8N, returning to user interface 868, user input 803N is received selecting charger option 876-1. In some embodiments, in response to user input 803n, device 500 displays a user interface 888, as shown in fig. 8O. In some embodiments, the user interface 888 includes a list 890 and an adapter option 892. In some embodiments, list 890 indicates a default plug type for vehicle 1. In some embodiments, the default plug type is the type of plug currently installed on the vehicle 1. In some embodiments, the default plug type is automatically selected based on information received from the vehicle 1 application. In some embodiments, list 890 is selectable to change the type of plug installed (e.g., if the user performs an after-market modification to the default plug type). In some embodiments, the adapter option 892 is selectable to add one or more adapter plugs to the map application. The adapter plug is optionally a mechanism/device that converts the default plug type to one or more other plug types. For example, plug type 1 may be compatible with only charging stations that accept plug type 1, but will not be compatible with charging stations that are compatible with only plug type 2. Thus, the plug adapter may 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 be compatible with vehicle 1, etc.).

In some embodiments, if the respective vehicle is not an electric vehicle, but a vehicle of a different fuel type (e.g., a gasoline vehicle, a plug-in hybrid vehicle, an E85 vehicle, etc.), the charger option 876-1 is optionally not displayed on the user interface 868, or the user interface 888 includes default tools for refueling or charging the vehicle, including options for adding a compatible adapter to the respective vehicle.

In fig. 8O, user input 803O is received selecting adapter option 892. In some embodiments, in response to user input 803o, device 500 displays user interface 894, as shown in fig. 8P. The user interface 894 includes a list of adapters that are selectable to indicate to the map application that the user owns. In some embodiments, the list of adapters includes only adapters compatible with the vehicle 1 (e.g., only adapters compatible with the vehicle (optionally, not adapters incompatible with the vehicle), only adapters compatible with the plug type of the vehicle (optionally, not adapters incompatible with the plug type of the vehicle), etc. In some embodiments, the adapter list is received from the vehicle 1 application. In some embodiments, the adapter list includes all existing adapters of any plug type.

In FIG. 8P, user input 803P is received selecting adapter option 896-2. In some embodiments, in response to user input 803p, adapter 2 is selected to be added as an available adapter for vehicle 1, as shown in fig. 8Q (e.g., represented by a check mark icon). In FIG. 8Q, user input 803Q is received selecting adapter 896-3 corresponding to adapter 3. In some embodiments, 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.

In fig. 8R, user input 803R selecting the "done" option is received, thereby completing the addition of adapter 2 and adapter 3 and eliminating user interface 894, as shown in fig. 8S. In FIG. 8S, user interface 888 now includes adapter lists 898-1 and 898-2 corresponding to the added adapters 2 and 3, respectively. In some embodiments, based on the plug type and the list of available adapters, the map application can suggest charging stations that are compatible with vehicle 1 (e.g., compatible with plug type 1 and/or compatible with plug type 1 using either adapter 2 or adapter 3). In some embodiments, the device 500 may provide a list of different compatible adapters for vehicles other than electric vehicles. For example, a corresponding hydrogen energy vehicle may be compatible with certain fuel pump types and may require certain adapters to hydrogenate at a particular hydrogen fuel station.

In fig. 8T, a user input 803T is received selecting a charger option 876-2 corresponding to a charging network. In some embodiments, in response to user input 803t, device 500 displays user interface 899, as shown in fig. 8U. In some embodiments, the user interface 899 includes a list of one or more charging networks operating in a user geographic area (e.g., in a country, in a state/province, in a city, in a region, etc.). In FIG. 8U, user interface 899 includes a charging network 897-1, a charging network 897-2, and a charging network 897-3. As shown in fig. 8U, the charging network 897-3 automatically initiates the population, optionally based on information received from the vehicle 1 application. For example, 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 compatible only with charging network 897-3). In some embodiments, charging network 897-3 may be a charging network recommended by the manufacturer of vehicle 1. As shown in fig. 8U, the user can select any charging network list to indicate to the map application that the user wishes to use to charge the charging network for the vehicle 1. In fig. 8U, a user input 803U is received selecting the charging network 897-2. In response to selection of charging network 897-2, the map application will suggest to vehicle 1 only charging parking spots within charging network 897-2 (e.g., selection of a charging network selects the corresponding charging network as the only compatible charging network). In some implementations, in response to selection of charging network 897-2, the map application will suggest to vehicle 1 a charging parking spot within both charging network 897-2 and charging network 897-3 (e.g., selection of a charging network switches the respective charging network as a compatible charging network).

In some embodiments, if the respective vehicle is not an electric vehicle, but a vehicle of a different fuel type (e.g., a gasoline vehicle, a plug-in hybrid vehicle, an E85 vehicle, etc.), the charger option 876-2 is optionally not displayed on the user interface 868, or the user interface 899 includes a network of fueling stations for compatibility with the fuel type of the respective vehicle (e.g., options corresponding to different fueling station brands, etc.). For example, for a gasoline vehicle, the user interface 899 may include options for different gas station brands that are selectable so that the map application will suggest only gas stations of the selected gas station brand.

Fig. 8V-8 CC illustrate embodiments in which the map application displays information or suggestions based on information received from the vehicle 1 application (and/or defined in a vehicle settings user interface, as previously described). It should be appreciated that although the embodiment shown herein describes receiving information from a vehicle 1 application, information may be received from any source external to the map application, such as a server external to the device 500.

It should be appreciated that while the description of the figures below describes an embodiment in which the device 500 determines one or more suggested routes and/or determines one or more suggested stops, the determination may be performed by a navigation server or by a combination of the device 500 and the navigation server, the results of which are provided to the device 500 for display in a user interface.

In fig. 8V, the device 500 displays a user interface 800 when the vehicle 1 is selected. In fig. 8V, user interface 800 is similar to user interface 600 described in fig. 6A and includes a location indicator 883. In some embodiments, the position indicator 883 has visual characteristics based on the visual characteristics of the vehicle 1. For example, in FIG. 8V, the location indicator 883 has the same visual characteristics as the visual characteristics of the icon 884 and color options 886-16 described above in FIG. 8M.

In fig. 8V, a user input 803V is received requesting guidance from the current location to destination 1. In response to user input 803v, device 500 displays one or more suggested routes, as described above in connection with method 700. In some embodiments, proposed routes 887-1 and/or 887-2 include one or more proposed stops to refuel and/or charge vehicle 1. As shown in fig. 8W, the current charge level of the vehicle 1 is such that the vehicle 1 has a driving range of 20 miles. In some embodiments, the map application receives current range information (e.g., 20 miles) from the vehicle 1 application and/or current power information (e.g., 5% power) from the vehicle 1 application. Based on the received information, the device 500 determines that a charging stop is required and includes the charging stop on one or more proposed routes. In some embodiments, the selected charging parking spot is within the charging network selected in fig. 8U above (e.g., optionally provided by the vehicle 1 application) and compatible with the plug type of the vehicle 1 (optionally with or without one of the available adapters). In some embodiments, the location and presence of the charging parking spot is received from the vehicle 1 application or from a database external to the vehicle 1 application. In some embodiments, if the user has selected a different set of adapters and/or has selected a different charging network, the suggested route and/or suggested parking spot provided by device 500 may be different than those shown herein based on whether a particular charging station is compatible with a particular adapter and/or based on whether a particular charging station is within the selected charging network. For example, in fig. 6K-6L, the selected charging network is "Gigawatts", so the proposed parking spot is within the "Gigawatts" charging network, and the proposed parking spot of the proposed route 887-1 is within the "Ionize" charging network (which is compatible with the user-selected adapter in fig. 8P-8R).

Thus, as shown in fig. 8W, the route suggested to the user is based on the characteristics of the vehicle 1 received from a source external to the map application (e.g., the vehicle 1 application or an external server).

FIG. 8W shows an embodiment similar to FIG. 6M in which user input 803W requesting navigation using the proposed route 887-1 is received. In some embodiments, in response to user input 803w, device 500 enters a navigation mode and displays step-by-step and/or step-by-step navigation to navigate to a destination along suggested route 887-1. In some embodiments, the device 500 displays a representation of the vehicle based on characteristics received from an external source when in the navigation mode. For example, in fig. 8X, an icon 873 representing the current position of the vehicle may have the same color as the position indicator 883 and the icon 884, based on color information received from the vehicle 1 application. In some embodiments, icon 873 does not have a color based on the vehicle color.

Fig. 8X shows an embodiment similar to fig. 6P, wherein the user has arrived at the proposed charging station. As shown in fig. 8X, the proposed charging station is within the charging network (e.g., "Ionize" charging network) selected in fig. 8U above. In fig. 8X, instruction 877 indicates an adapter (e.g., "adapter 2") required to connect the vehicle 1 with a charging station. As described above, in some embodiments, the device 500 only suggests use of an adapter that the user and/or vehicle 1 application has indicated is available to the vehicle 1.

Fig. 8Y shows an embodiment similar to fig. 6Q, wherein the device 500 has determined that the vehicle 1 has started charging. In some embodiments, the device 500 receives information from the vehicle 1 application that the vehicle 1 has begun charging (e.g., receives charging and/or battery level information). In some embodiments, in accordance with a determination that the vehicle 1 has begun charging, the device 500 updates the instructions 879 to display the remaining time to charge to the recommended charge level. In some embodiments, the information 879 includes an indication of the current charge level.

Fig. 8Z shows an embodiment similar to fig. 6Q, in which the vehicle 1 has been charged to 34%. In some embodiments, the instructions 879 are updated to reflect the updated state of charge. For example, in fig. 8Z, instruction 879 reads "8 minutes remaining" based on an estimated remaining length of time to charge to 53%, based on a charge rate and/or based on a current charge level received from the vehicle 1 application.

Fig. 8AA shows an embodiment similar to fig. 6V, where the device 500 is in a navigation mode and the device 500 determines that a charging stop is needed to reach the destination based on updated charge information. In some embodiments, the map application receives updated power information (e.g., 10% power) and/or updated distance travelled information (e.g., 20 miles, 40 miles, etc.) from the vehicle 1 application and determines that a charging stop is needed. In accordance with a determination that a charging stop is desired, the device 500 displays a proposed route that includes a proposed stop within the selected charging network (optionally compatible with the plug type of the vehicle 1).

It should be appreciated that while the above embodiments relate to an electric vehicle, this is merely exemplary and the above features are not limited to electric vehicles. For example, the ability to link a map application to an application associated with a vehicle may be performed for any fuel type vehicle (e.g., a gasoline vehicle, a hybrid vehicle, a plug-in hybrid vehicle, etc.), and the map application may receive information regarding the characteristics of any fuel type vehicle. Similarly, the map application may determine (optionally, the navigation server may determine) a suggested route and/or a suggested parking spot based on the type of fuel used by the selected vehicle (e.g., gas station, electric vehicle charging station, hydrogen gas station, E85 station, chai Youzhan, etc.).

Fig. 8BB to 8CC show embodiments in which the vehicle 1 application is installed on the device 500 but has not yet been linked to the map application. In fig. 8BB, when the vehicle 1 application has been installed but not yet linked (e.g., the vehicle 1 is not selected and/or the map application does not access information about the characteristics of the vehicle 1), a user input 803BB requesting guidance from the current location to the destination 1 is received, similar to the embodiment described in fig. 6A-6B. In some embodiments, in response to user input 803bb, device 500 displays suggested route 887-5 and suggested route 887-6. As shown in fig. 8CC, the proposed route 887-5 and the proposed route 887-6 are selected and/or determined without regard to the characteristics of the particular vehicle 1. Thus, in FIG. 8CC, proposed route 887-5 is the fastest route from the current location of the device to destination 1, excluding any proposed parking points for charging and/or fueling, and proposed route 887-6 is an alternative route to proposed route 887-5, also excluding any proposed parking points for charging and/or fueling. Therefore, as shown in the figure, even if the vehicle 1 application is installed, because the vehicle 1 application is not linked with the map application, the map application cannot receive information about the current characteristics of the vehicle 1 and cannot provide a suggested parking spot based on the current characteristics of the vehicle 1 received from an external source. However, it should be appreciated that the map application can provide customized suggested parking spots based on other information not received from the vehicle 1 application or external sources. For example, even if the vehicle 1 application is not installed, the user is optionally able to manually add the vehicle 1 to the map application and provide license plate information and receive a customized route based on whether the vehicle 1 is subject to travel restrictions, as described above in connection with fig. 6W-6 FF. On the other hand, if the vehicle 1 application is linked to the map application, the map application may optionally receive license plate information from the vehicle 1 application and provide a customized route for the vehicle 1 based on the received information.

Fig. 9 is a flowchart illustrating a method 900 of receiving information regarding respective vehicle characteristics according to some embodiments of the present disclosure. Method 900 is optionally performed on an electronic device (such as device 100, device 300, and device 500) as described above with reference to fig. 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.

As described below, method 900 provides a way to receive information regarding characteristics of a respective vehicle. The method reduces the cognitive burden on the user when interacting with the device user interface of the present disclosure, thereby creating a more efficient human-machine interface. For battery-operated electronic devices, improving the efficiency of user interaction with the user interface saves power and increases the time between battery charges.

In some embodiments, the electronic device 500 (in communication with one or more of a display generation component (e.g., a mobile device (e.g., a tablet, a smart phone, a media player, or a wearable device) or a computer, optionally with a mouse (e.g., external), a track pad (optionally integrated or external), a touch pad (optionally integrated or external), a 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) a map user interface of a map application via the display generation component, such as user interface 800 in fig. 8A (e.g., a user interface displaying a representation of a map of a given geographic location).

In some embodiments, the display generating component is a display integrated with the electronic device (optionally a touch screen display), an external display such as a monitor, projector, television, or hardware component (optionally integrated or external) for projecting a user interface or making the user interface visible to one or more users, or the like.

In some implementations, the user interface is a user interface of a map application. In some implementations, the map user interface can be interacted with by a user to view different geographic locations or to change the zoom level of the map.

In some embodiments, the map user interface includes a representation of the map (e.g., a representation of a geographic location) and corresponding information (904), such as suggested routes 887-1 and suggested routes 887-2 in fig. 8W (e.g., icons representing electronic devices and optionally indicating a determined current location of the devices). In some embodiments, the respective information includes one or more routes for traveling from one location to another. In some embodiments, the corresponding information is based on characteristics of the vehicle (e.g., color, shape, size, model number, mileage, fuel type, etc.). In some embodiments, the respective information is based on the selected traffic pattern.

In some embodiments, in accordance with a determination that information corresponding to a characteristic of the first vehicle (e.g., a current and/or real-time state or characteristic of the first vehicle) has been enabled to be received by the map application from a source external to the map application (e.g., the map application is configured to receive information from the external source that affects guidance from the first location to the second location and/or display of routes), 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 a current range of vehicle 1 in fig. 8W (e.g., one or more suggested routes from the first location to the second location are based on the received information).

In some embodiments, the external source is an application installed on the electronic device separate from the map application associated with the first vehicle. In some implementations, 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. In some embodiments, the external source is another electronic device (e.g., external to the electronic device but in wired or wireless communication with the device). In some embodiments, the current characteristics of the first vehicle include fuel information (e.g., available fuel amount, available power amount), an estimated distance that the current fuel (or power amount) level may travel, a type of fuel used by the vehicle (or a type of charger desired), and/or a physical characteristic of the first vehicle (such as color, size, shape, etc.). In some implementations, information corresponding to characteristics of the first vehicle is received from a plurality of sources (e.g., a plurality of applications, a plurality of servers, etc.) external to the map application. In some embodiments, the information is information other than the current location of the vehicle and/or one or more geographic locations (e.g., landmarks, etc.). In some embodiments, the information includes a current location of the vehicle. In some embodiments, a particular source provides information about characteristics of multiple vehicles (e.g., an application is associated with and capable of providing information about one or more vehicles). In some embodiments, the map application is configured to receive information from a plurality of external sources. In some implementations, each source is associated with a different vehicle (e.g., a first application is associated with a first vehicle, a second application is associated with a second vehicle, etc.).

In some embodiments, the proposed route includes a proposed stopping point for fueling and/or charging. In some embodiments, the proposed route includes a proposed stopping point because the current fuel level (or charge level) received from an external source does not enable the vehicle to reach the destination without refueling (or charging). In some embodiments, the suggested parking spot depends on the type of charging station or gas station required to provide the desired charge or fuel to the vehicle (e.g., a particular type of charging station, a particular type of gas station providing a particular type of fuel such as diesel or E85). In some embodiments, the first information is a representation of the first vehicle, such as an icon or model of the first vehicle reflecting a physical characteristic (e.g., having a color and/or shape representative of the first vehicle). In some implementations, the first information is information other than location information (e.g., a current location of the vehicle, a starting location of the navigation directions, a destination location of the navigation directions, landmarks, favorite locations, etc.). In some implementations, for each external source from which the map application is receiving information, the map application can display information based on characteristics of the respective vehicle associated with the external source. For example, if 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 can 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. In some embodiments, the first information, the second information, and the third information are displayed simultaneously or separately when the respective vehicle is selected in the map application. In some implementations, the respective information includes an icon representing the user's vehicle (e.g., at a location on a representation of a map corresponding to the determined current location of the device). In some embodiments, the icon has one or more visual characteristics based on the visual characteristics of the user vehicle. In some embodiments, the icon is a cartoon or cartoon of the user's vehicle. For example, the icon is an automobile having the same or similar color and/or shape as the first vehicle.

The above-described manner of displaying information based on received information regarding characteristics of a particular vehicle (e.g., if a map application is able to receive information from a source external to the map application) quickly and efficiently customizes information for a particular vehicle (e.g., by displaying information based on the received current characteristics of the vehicle), which simplifies interactions between a user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to separately determine whether the resulting information is suitable for the vehicle or perform additional inputs to manually edit a proposed route to include a desired fueling or charging stop), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, 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 a map, a vehicle representation on a map, etc.). In some embodiments, the method includes receiving, by the map application, information corresponding to a characteristic of the first vehicle from a source external to the map application, the respective information being a respective type of second information, wherein the second information is not based on the characteristic of the first vehicle, such as the proposed route 887-5 and the proposed route 887-6 in FIG. 8CC, and not based on a range of any vehicle (e.g., if the map application is not configured to receive information from an external source, information not based on the characteristic of the particular vehicle is displayed.

The above-described manner of displaying information other than based on received information regarding vehicle characteristics (e.g., if a map application is unable to receive information from a source external to the map application) provides generic map information or custom map information quickly and efficiently, which simplifies interactions between a user and an electronic device, enhances operability of the electronic device, and makes a user-device interface more efficient (e.g., enables or disables custom information by automatically providing custom information if the custom information is available, without requiring additional input by the user) by enabling the user to use the electronic device faster and more efficiently while reducing errors in device usage and additionally reducing power usage and extending battery life of the electronic device.

In some embodiments, the respective information (e.g., the request to display one or more routes and/or directions from the first geographic location to the second geographic location, and the respective information is one or more suggested routes for traveling from the first location to the second location) is displayed in response to a user input (such as user input 803 in fig. 8V) corresponding to the request to display directions from the first location to the second location.

For example, the user inputs a travel guidance requesting from a first location to a second location. In some embodiments, the user selects the first geographic location and/or the second geographic location. In some implementations, the first geographic location or the second geographic location is a determined current location of the electronic device. In some implementations, the map user interface displays one or more determined routes from the first geographic location to the second geographic location. In some embodiments, one or more suggested routes are displayed overlaid on the representation of the map.

The above-described manner of displaying a customized route based on received information regarding a particular vehicle characteristic quickly and efficiently customizes the information for the particular vehicle (e.g., by displaying a proposed route based on the vehicle characteristic), which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., by automatically using information received from an external source without requiring the user to manually edit the proposed route to include a desired fueling or charging stop by separately determining whether the resulting information is suitable for the vehicle or performing additional inputs), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the characteristics of the first vehicle include a current estimated distance that the first vehicle is able to travel, such as 20 miles of vehicle 1 in fig. 8W (e.g., the estimated distance of the first vehicle is received from a source external to the map application). In some embodiments, the characteristic of the first vehicle includes a current charge level or a current fuel level of the first vehicle. In some embodiments, the corresponding information is based on an estimated range of the first vehicle. For example, the corresponding information includes one or more proposed routes, and the one or more proposed routes optionally include one or more proposed stopping points for fueling or charging the vehicle (e.g., if the estimated range is less than the distance traveled by the one or more proposed routes), as described above in connection with method 700.

The manner in which information is displayed based on the estimated distance that a vehicle can travel described above quickly and efficiently displays custom travel information for a particular vehicle, which simplifies interactions between a user and an electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to separately determine whether the resulting information is appropriate for the vehicle), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the characteristics of the first vehicle include a charger type compatible with the first vehicle, such as adapter 2 in fig. 8X (e.g., a charger type received from a source external to the map application that may be used to charge the first vehicle).

In some embodiments, different electric vehicle charging stations have different plugs and/or are compatible with different types of connectors. In some embodiments, different electric vehicles have different plugs and/or are compatible with different types of connectors. In some embodiments, there are adapters that allow an electric vehicle to convert a plug mounted on the electric vehicle into a plug type compatible with the corresponding charging station. In some implementations, a source external to the map application provides information to the map application regarding what types of chargers are compatible with the first vehicle and, optionally, which adapters are compatible with the first vehicle (e.g., connected to different types of chargers). In some implementations, based on information regarding what type of charger is compatible with the first vehicle, the map application can suggest to use charging stations of the charger type that are compatible with the first vehicle (e.g., via use of an adapter or without an adapter). In some implementations, the map application does not suggest charging stations that do not use a charger type (e.g., with or without an adapter) that is compatible with the first vehicle.

The manner in which information is displayed based on the type of charger compatible with a particular vehicle described above quickly and efficiently determines charging stations compatible with a first vehicle (e.g., by automatically determining whether the charging stations use a type of charger compatible with the vehicle), which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to separately determine whether a proposed charging station is compatible with the user vehicle), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the characteristics of the first vehicle include a vehicle type, such as the make and model of the vehicle 1 in fig. 8N (e.g., a source external to the map application provides information about the make, model, and/or color of the first vehicle). In some embodiments, the map application displays a representation of the first vehicle based on the make, model, and/or color of the first vehicle. In some implementations, the representation of the first vehicle is displayed on a representation of a map (e.g., traveling on a road, parked at a building, etc.) at a currently determined location of the electronic device (e.g., via one or more location sensors such as GPS). In some implementations, the representation of the first vehicle is displayed at a currently determined location of the first vehicle (e.g., based on location information received from a source external to the map application). For example, an icon of the first vehicle is displayed in a map user interface having 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 based on the make and model of the first vehicle.

The above-described manner of receiving the vehicle type of a particular vehicle quickly and efficiently customizes information for the particular vehicle (e.g., by displaying information based on the selected vehicle type), which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient, which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the characteristics of the first vehicle include a current charge level of the first vehicle, such as 15% and 34% charge levels in fig. 8Y and 8Z (e.g., the current charge level or the current fuel level of the first vehicle is received from a source external to the map application). In some implementations, the respective information displayed includes a current power level or a current fuel level based on information received from a source external to the map application. In some embodiments, the corresponding information displayed includes one or more proposed routes, and the one or more proposed routes optionally include one or more proposed stopping points selected to refuel or charge the vehicle based on the current charge level or the current fuel level of the first vehicle (e.g., if the current charge or fuel level would not enable the first vehicle to reach the destination without refuelling or charging), as described above in connection with method 700.

The above-described manner of displaying information based on a current power level of a particular vehicle quickly and efficiently customizes information for a particular vehicle (e.g., by displaying a customized route based on whether the current power level is sufficient to reach a destination), which simplifies interactions between a user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to separately determine whether the vehicle can reach the destination using a proposed route), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the first information includes one or more proposed routes that travel from the first location to the second location using the first vehicle, such as proposed route 887-1 and proposed route 887-2 in fig. 8W (e.g., the corresponding information displayed includes one or more proposed routes from the first location to the second location). In some embodiments, one or more proposed routes are selected and/or determined based on the received information regarding the characteristics of the first vehicle. For example, the map application may receive an estimated range of the first vehicle from an external source and using the estimated range information, the map application may add one or more suggested stopping points to refuel or charge the first vehicle. In some implementations, the map application may suggest a different route, such as a shorter route or a route that facilitates higher efficiency (e.g., fuel or power savings) based on the estimated range of the first vehicle. In some embodiments, 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 high, or too heavy, or any other travel limit, such as those described above in connection with method 700).

The above-described manner of displaying a proposed route based on received information for a particular vehicle quickly and efficiently customizes the information for a particular vehicle (e.g., by receiving information regarding the current state of the vehicle and using the received information to select the proposed route for the vehicle), which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to separately determine whether the vehicle can travel along the route without stopping to refuel or charge and does not require separately seek an appropriate gas station or charging station), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the characteristic of the first vehicle includes a current estimated distance that the first vehicle is capable of traveling, and a first proposed route of the one or more proposed routes includes a proposed parking spot to charge a battery of the first vehicle, such as proposed parking spot 885 in fig. 8W (e.g., based on received information of the estimated travel distance of the first vehicle for the current fuel or electric level of the first vehicle, the proposed route includes one or more proposed parking spots to refuel or charge the first vehicle (e.g., such as at a gas station or a charging station)).

In some embodiments, a stopping point to refuel or charge the vehicle is suggested if the vehicle will not be able to reach the destination, will consume fuel or electricity before reaching the destination, will reach the destination with less than a threshold amount of fuel or electricity (e.g., less than 5%, 10%, 15%, 20%, 25%, 30%, etc. of fuel or electricity), and/or remain with less than a threshold amount of estimated range (e.g., 5 miles, 10 miles, 15 miles, 30 miles, 50 miles, etc. of remaining range), as described above in connection with method 800.

The above-described manner of suggesting a stop point to charge a vehicle based on received information of a current estimated distance that the vehicle can travel quickly and efficiently suggests a stop point required to charge the vehicle (e.g., by automatically determining that a charge stop point is required, finding an appropriate charging station, and adding a charge stop point to a suggested route), which simplifies interactions between a user and an electronic device, enhances operability of the electronic device, and makes a user-device interface more efficient (e.g., does not require the user to separately determine whether the vehicle can travel along a route without stopping to refuel or charge and does not require separately find an appropriate gas station or charging station), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, in accordance with a determination that an application associated with the first vehicle that is different from the map application is installed on the electronic device, the electronic device displays an affordance, such as button 814 in fig. 8D, in the map user interface that corresponds to the application associated with the first vehicle (e.g., determines that the application associated with the first vehicle is installed on the device before the first vehicle is added to the map application).

In some embodiments, the application associated with the first vehicle is a third party application (e.g., such as from a vehicle manufacturer). In some embodiments, an application associated with the first vehicle is capable of accessing and displaying information about the first vehicle. For example, an application associated with the first vehicle may access a fuel or power level of the first vehicle, a range of the first vehicle, a travel efficiency of the first vehicle, a travel history of the first vehicle, a tire pressure status of the first vehicle, an estimated range of the first vehicle, and/or any other vehicle status information. In some implementations, the map user interface includes selectable options to link an application associated with the first vehicle with the map application if the first vehicle has not been added to the map application (e.g., such as described above in connection with method 700) and/or if an application associated with the first vehicle has not been linked with the map application. In some embodiments, if the application associated with the first vehicle is not installed on the electronic device, an affordance linking the map application with the application associated with the first vehicle is not displayed.

In some implementations, the electronic device receives user input selecting the affordance via one or more input devices, such as in fig. 8D. In some embodiments, in response to receiving user input selecting the affordance, the electronic device initiates a process that enables the map application to receive information corresponding to characteristics of the first vehicle from an application associated with the first vehicle, such as in fig. 8E-8G (e.g., initiates a process of linking the map application with an application associated with the first vehicle).

In some embodiments, linking the application to which the first vehicle is associated with the map application enables information accessible from the application to which the first vehicle is associated to be accessed by and/or from the map application. In some embodiments, the map application receives and/or accesses information available to the application having the first vehicle to customize information displayed in the map user interface based on the received information. In some embodiments, information is received from an application to which the first vehicle is associated. In some implementations, information is received from a server external to the electronic device (e.g., using information received from a first application that enables the map application to communicate with the server).

The manner in which the above-described display of an affordance linking the map application with the application to which the particular vehicle is associated (e.g., if it is determined that the application is installed on the electronic device) provides the user with a quick and efficient method for linking the map application with the application to which the vehicle is associated (e.g., by automatically determining that the application is installed and providing selectable options linking the map application with the application of the vehicle), which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to determine whether information is accessible to the user vehicle and does not subsequently perform additional inputs to enable the map application to receive information about the user vehicle), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the electronic device receives updated information about the first vehicle characteristic, such as the updated charge information in fig. 8AA (e.g., information about the first vehicle's characteristic is continuously or periodically updated) from a source external to the map application while the corresponding information is displayed. In some implementations, the map application periodically polls the information source for updated information. In some implementations, the source pushes the update to the map application in response to determining that there is an update to the characteristic.

In some embodiments, in response to receiving the updated information regarding the first vehicle characteristic, the electronic device updates the corresponding information based on the updated information regarding the first vehicle characteristic, such as new proposed route 887-4 with the proposed parking spot in fig. 8AA (e.g., based on the received updated information, updates the displayed information using the received updated information). For example, while displaying one or more proposed routes, if the map application receives updated information regarding the current range of the first vehicle, the map application changes the proposed route to account for any changes in range (e.g., if the range decreases, a proposed stopping point may be added to the proposed route). In some implementations, if the updated information does not affect the displayed information (e.g., does not affect the proposed route, or is not related to the proposed route), the device does not update the corresponding information based on the updated information.

The above-described manner of displaying updated information about a particular vehicle (e.g., when customized information for the vehicle has been displayed) provides updated information quickly and efficiently, which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to perform additional input to refresh information displayed to the user based on updated information), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the updated information regarding the first vehicle characteristic includes a current charge level of the first vehicle and updated information regarding the first vehicle characteristic is received while the first vehicle is charging, such as 15% and 34% charge levels in fig. 8Y-8Z (e.g., the corresponding information is the current charge level or current fuel level of the first vehicle and the map application is capable of receiving the updated fuel or charge level and displaying the updated fuel or charge level while the first vehicle is fueling or charging (and/or updating an estimated fuel or charge level associated with certain steps of the route, and/or determining an estimated time to fueling or charging the vehicle, and/or updating an expected time to destination based on fueling or charge rate)).

The above-described manner of displaying updated charge information as the vehicle charges provides updated charge information quickly and efficiently, which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to perform additional inputs to refresh the charge information), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, updating the respective information based on the updated information about the first vehicle characteristic is performed while providing navigation guidance for the first vehicle, and includes updating the navigation guidance based on the updated information about the first vehicle characteristic, such as the new proposed route with the new charging parking spot in fig. 8 AA. (e.g., updating or modifying the navigation directions based on the updated information when navigating along the proposed route to display the step-wise navigation directions). For example, in accordance with a determination that the range of the first vehicle is no longer sufficient to reach the destination (e.g., based on updated range information received from the source), one or more stopping points may be added to the navigation directions of the vehicle to charge or refuel.

The above-described manner of receiving update information as the vehicle navigates 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 update information and modifying the navigation directions if the update information indicates that the directions should be modified), which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to separately determine whether the navigation directions provided to the user need to be modified and does not perform additional inputs to manually modify the route or trigger a refresh of the suggested directions), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, updating the navigation directions based on the updated information about the first vehicle characteristic includes adding suggested stops to the navigation directions, such as in fig. 8AA (e.g., if based on the updated information, the device determines that the first vehicle will not be able to reach the destination without refueling or charging (or will optionally be able to reach the destination with less than a threshold amount of fuel or electricity (e.g., 5%, 10%, 15%, 20%, 25%, 30%, etc.) or with less than a threshold amount of remaining range (e.g., 5 miles, 10 miles, 15 miles, 30 miles, 50 miles, etc.), then one or more suggested stops are added at the gas station or charging station.

The above-described manner of adding a suggested parking spot based on updated information for a particular vehicle (e.g., if the updated information indicates that a refueling or charging parking spot is needed to reach a desired destination) quickly and efficiently monitors whether the vehicle will reach the destination (e.g., automatically receives updated information and determines whether the vehicle will still reach the destination or whether a parking spot is needed), which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., does not require the user to separately determine whether a parking spot is needed and does not require additional input to be performed to find a gas station or a charging station and does not require navigation guidance to add a parking spot), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

It should be understood that the particular order in which the operations in fig. 9 are described is merely exemplary and is not intended to suggest that the described order is the only order in which the operations may be performed. Those of ordinary skill in the art will recognize a variety of ways to reorder the operations described herein. Additionally, it should be noted that the details of other processes described herein in connection with other methods described herein (e.g., methods 700, 1100, and 1300) are likewise applicable in a similar manner to method 900 described above in connection with fig. 9. For example, the operations of the electronic device described above with reference to method 900 to receive information regarding the respective vehicle characteristics optionally have one or more of the characteristics described herein with reference to other methods described herein (e.g., methods 700, 1100, and 1300) to display a customized navigation route, anonymously process a vehicle identifier, valid route determination, etc. For the sake of brevity, these details are not repeated here.

The operations in the above-described information processing method are optionally implemented by running one or more functional modules in an information processing apparatus such as a general-purpose processor (e.g., as described with respect to fig. 1A-1B, 3, 5A-5B) or a dedicated chip. Furthermore, the operations described above with reference to fig. 9 are optionally implemented by the components depicted in fig. 1A-1B. For example, display operation 902 is optionally implemented by event sorter 170, event recognizer 180, and event handler 190. An event monitor 171 in the event sorter 170 detects a contact on the touch-sensitive surface 604 and an event dispatcher module 174 delivers event information to the application 136-1. The respective event identifier 180 of the application 136-1 compares the event information to the respective event definition 186 and determines whether the first contact at the first location on the touch-sensitive surface corresponds to a predefined event or sub-event, such as a selection of an object on the user interface. When a respective predefined event or sub-event is detected, the event recognizer 180 activates an event handler 190 associated with the detection of the event or sub-event. Event handler 190 optionally utilizes or invokes data updater 176 or object updater 177 to update the application internal state 192. In some embodiments, event handler 190 accesses a corresponding GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one of ordinary skill in the art how other processes may be implemented based on the components depicted in fig. 1A-1B.

Anonymously processing vehicle identifiers

Users interact with electronic devices in many different ways, including using the electronic device to view directions from one geographic location to another. In some embodiments, certain geographic locations impose travel restrictions, wherein certain automobiles may be prohibited from traveling in restricted areas based on one or more characteristics of the user's vehicle. For example, the geographic location may enforce a travel limit based on the value of the vehicle license plate. In some implementations, the electronic device provides an anonymous version of the vehicle license plate to the navigation server to receive a navigation route tailored to a particular vehicle (e.g., taking into account travel restrictions). The embodiments described below provide a way to anonymously process vehicle license plates and transmit the anonymously license plates to a navigation server to preserve user privacy. The license plate of the user is processed anonymously to ensure that personal information of the user is protected, interaction between the user and the electronic equipment is enhanced, and time required by the user to execute operation is shortened. Shortening the operating time reduces the power usage of the device and extends the battery life of the battery-powered device.

Fig. 10A-10P illustrate an exemplary manner in which a vehicle identifier is anonymously processed according to some embodiments of the present disclosure. The embodiments in these figures are used to illustrate the processes described below, including the processes described with reference to fig. 11. While fig. 10A-10P illustrate various examples of the manner in which an electronic device may be 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 that the electronic device may be able to perform one or more of the processes described below with reference to fig. 11 in a manner that is not explicitly described with reference to fig. 10A-10P.

Fig. 10A illustrates an electronic device 500 displaying a user interface 1000 (e.g., via a display device, via a display generation component, etc.). In some implementations, the user interface 1000 is displayed via a display generation component. In some embodiments, the display generation component is a hardware component (e.g., including electronic components) capable of receiving display data and displaying a user interface. In some embodiments, examples of display generating components 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 in communication with device 500.

In some implementations, the user interface 1000 is a user interface of a map application (e.g., similar to the user interface 800 described above in connection with fig. 8A). In some implementations, the map application is an application installed on the device 500.

In some implementations, the user interface 1000 includes a representation of a map having a current location of the electronic device. In fig. 10A, the user interface 1000 does not include any suggested route or travel guidance, and is optionally a default user interface of the map application (e.g., when in a browsing state) that includes a location indicator 1002 that represents the current location of the device 500 on a representation on a map. In fig. 10A, the device 500 also displays a user interface 1004. In some implementations, the user interface 1004 includes a search field 1006 for performing a search for a location or business. In some implementations, the user interface 1004 includes one or more shortcuts 1050 that are selectable to search for and display respective locations associated with respective shortcuts. For example, the one or more shortcuts 1050 can include a "home" shortcut optionally selectable to display a location associated with "home", a "workplace" shortcut optionally selectable to display a location associated with "workplace", and a "exercise facility" shortcut optionally selectable to display a location associated with "exercise facility".

In some embodiments, the travel limit corresponds to a limit that defines that a particular group of vehicles may travel unrestricted and that a second group of vehicles is restricted from traveling. In some embodiments, other restrictions are possible (e.g., a first set of vehicles must follow a particular set of rules or regulations, while a second set follows a different set of rules or regulations, or all vehicles with particular characteristics are restricted from traveling, etc.). For example, if a particular region or road group is subject to travel restriction control, certain vehicles having certain characteristics defined by the restriction may be restricted to travel within the region (or on the road), while other vehicles without these certain characteristics may not be restricted to travel within the region (or on the road). For example, there may be a limit in which an odd license plate (e.g., a vehicle with an odd license plate tail number) is prohibited from traveling at a particular location during a particular time and date, and an even license plate (e.g., a vehicle with an even license plate tail number) is not prohibited from traveling at a particular location at any time (or from traveling at a particular location during other times). In some embodiments, other vehicle identifiers are possible, such as a Vehicle Identification Number (VIN). Another example of a travel limit may be to prohibit vehicles exceeding a certain total weight from traveling on a certain highway during business hours, and not to prohibit vehicles below the total weight threshold from traveling on the highway.

As used herein, a restricted area is a geographic area in which corresponding travel restrictions apply. For example, if the travel limit indicates that odd license plates are prohibited from traveling in a particular geographic area, but even license plates are not prohibited from traveling in that particular geographic area, the entire geographic area in which the limit is applied is optionally referred to as a limited area.

As shown in fig. 10A, the user interface 1004 includes an indication 1008 (e.g., sharing similar features as the indication 812 described above in connection with fig. 8B). In some implementations, the indication 1008 includes a description of adding license plate information to the map application. In some implementations, the indication 1008 includes a button 1010 that is selectable to initiate a process of adding license plate information to the map application.

In some embodiments, the indication 1008 is displayed at or near the restricted area where the vehicle is prohibited (e.g., in or within 10 miles, 30 miles, 50 miles, 100 miles, etc. of the restricted area) based on the vehicle-based license plate number determination device 500. In some implementations, if the map application does not already have any license plate information, an indication 1008 is displayed. For example, after the user completes the process of adding a license plate to the map application (as will be described in more detail below), the indication 1008 will no longer be displayed in the user interface 1004. In some implementations, the indication 1008 is displayed even though the user has previously added license plate information to the map application.

In some implementations, the user can add license plate information to the map application via a settings user interface of the map application (e.g., without requiring display of an indication 1008 in the user interface 1004). For example, similar to user interface 862 described above in connection with fig. 8J, a user can initiate a process of adding license plates by adding vehicles to a map application via a user interface for managing vehicles that have been added to the map application. For example, the user interface 862 may include one or more options for adding vehicles, editing vehicles, and/or deleting vehicles from the map application. In such implementations, the user can initiate a process of adding the vehicle to the map application and provide license plate information for the added vehicle (e.g., similar to the process of adding a license plate to the map application in response to selection of button 1010 as described below).

In some embodiments, providing license plate information to the map application allows an electronic device (e.g., device 500) to display one or more suggested routes based on whether the user's vehicle is prohibited from traveling in a restricted area, similar to the process described above in connection with method 700. In some implementations, the proposed route is determined by transmitting a request for a navigation route to a navigation server (e.g., route server) and receiving one or more possible navigation routes in response. In some embodiments, the navigation server can receive anonymous license plate information (or other anonymous vehicle identifiers, such as anonymous VIN numbers, anonymous serial numbers, etc.) and provide a navigation route based on whether the provided anonymous vehicle identifier falls within a limit (e.g., vehicle travel in a limited area is prohibited) or falls outside of a limit (e.g., vehicle travel in a limited area is not prohibited).

As will be described in greater detail below, the device 500 is capable of preserving user privacy by modifying one or more values of a user vehicle identifier (e.g., license plate, VIN number, etc.), thereby anonymously processing the vehicle identifier before transmitting the anonymous vehicle identifier to a navigation server. In some embodiments, vehicle identifier information (e.g., non-anonymous license plates, actual license plates, etc.) provided by the user is stored on the device 500 and is not transmitted from the device 500 at all. In some embodiments, the vehicle identifier information provided by the user is deleted from the device 500 after the anonymous vehicle identifier is generated (e.g., in response to generating the anonymous license plate or in response to transmitting the anonymous license plate to a navigation server).

In fig. 10A, user input 1003a selecting button 1010 is received. In some embodiments, in response to user input 1003, device 500 initiates a process of adding license plate information to a map application, as shown in fig. 10B. In fig. 10B, device 500 displays user interface 1012. The user interface 1012 is optionally a launch page or introduction page for adding license plate information to the map application. For example, the user interface 1012 may include an introduction 1014 describing the process of providing license plate information to the map application and/or the beneficial effects of providing license plate information to the map application. In some implementations, the user interface 1012 includes a button 1016 that can be selected to continue the process of adding license plate information to the map application. In some implementations, the user interface 1012 includes a button 1018 that is selectable to terminate the process of adding license plate information to the map application. As described above, after terminating the process of adding license plate information to the map application, the user can initiate the process via the setup user interface of the map application.

In fig. 10B, the user receives user input 1003B selecting button 1016. In some embodiments, in response to user input 1003b, device 500 continues the process of adding license plate information to the map application and displaying user interface 1020, as shown in fig. 10C. In some embodiments, the user interface 1020 includes one or more options for selecting a geographic region to 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, and so on. In some implementations, different geographic areas may have different license plate patterns or license plate values, and providing the map application with the respective areas to which the vehicle is registered enables the map application to verify that the license plate is valid (e.g., has the correct number of bits, has a valid value for the respective bits, etc.).

In some embodiments, the device 500 prioritizes or otherwise visually emphasizes one or more regions based on the current location of the device 500. For example, in fig. 10C, device 500 determines that device 500 is located in region 1 via one or more location determination processes (e.g., GPS data, cellular tower triangulation, etc.). Thus, in accordance with a determination that device 500 is located in zone 1, user interface 1020 displays an option 1022-1 corresponding to zone 1 at a location on user interface 1020 that is separate from the options of the other zones, as shown in FIG. 10C. Thus, the device 500 can suggest an area to the user by displaying area 1 as a first option that is visually distinct from other areas, thereby increasing the efficiency of the device by emphasizing more likely options to the user.

In FIG. 10C, user input 1003C is received by selecting option 1022-2 corresponding to region 2. In some embodiments, in response to user input 1003c, device 500 displays user interface 1024. In some embodiments, the user interface 1024 is a user interface for entering a license plate number. For example, in FIG. 10D, user interface 1024 includes an entry 1026 for entering a license plate number and an entry 1028 for selecting a vehicle fuel type. In fig. 10D, because the user selects region 2, the device 500 is able to automatically determine that the vehicles registered in region 2 have the same first character, and thus the device 500 automatically populates the entry 1026 with the first character 1030 (e.g., the "β" character). In some implementations, the apparatus 500 may set license plate numbers or limit available values for respective numbers of digits based on license plate patterns of the selected region.

It should be appreciated that while FIG. 10D shows the user interface 1024 including an entry 1026 corresponding to a license plate number and an entry 1028 corresponding to a fuel type, more or fewer entries are possible and neither entry need be displayed. For example, if the geographic area considers the license plate number of the vehicle, but does not consider the fuel type of the vehicle when making the travel limit determination, the user interface 1024 may include only a single entry for entering the license plate number and not an entry for providing the fuel type. Similarly, if the geographic area considers the fuel type of the vehicle but does not consider the license plate number of the vehicle, the user interface 1024 may include only a single entry for providing the fuel type and not an entry for providing the license plate number. Other embodiments are possible for other characteristics of the vehicle and/or the vehicle identifier. In some embodiments, any combination and any number of entries are possible.

FIG. 10E shows an alternative embodiment in which user input 1003E is received selecting option 1022-1 corresponding to region 1. In some embodiments, region 1 has a different license plate pattern than region 2. For example, in response to user input 1003e, device 500 displays user interface 1024 with entry 1026 automatically populated with a first character 1032 (e.g., a "θ" character) that is different from first character 1030 as shown in fig. 10F. Thus, in the embodiment shown in fig. 10C to 10F, the license plates in the region 1 all have "θ" as the first character, and the license plates in the region 2 all have "β" as the first character. It should be appreciated that the device 500 is capable of adapting to any license plate style for any geographic region and automatically populating one or more characters if the corresponding number of bits of the license plate is fixed for the corresponding region.

In some embodiments, based on determining that device 500 is located in zone 1, device 500 automatically selects option 1022-1 corresponding to zone 1 as the registration zone for the added vehicle. In such an embodiment, the device 500 does not display the user interface 1020, but proceeds to the user interface 1024 as if the option 1022-1 corresponding to region 1 was selected.

In fig. 10F, the user receives user input 1003F selecting item 1026. In some embodiments, in response to user input 1003f, device 500 displays virtual keyboard 1036 for entering characters into entry 1026, as shown in fig. 10G. For example, in fig. 10G, the user has provided a character 1034 (e.g., by selecting a key on virtual keyboard 1036) that, in combination with the first character 1032, corresponds to the license plate of the user's vehicle to be added to the map application.

In fig. 10G, user input 1003G is received selecting entry 1028. In some embodiments, in response to user input 1003g, device 500 displays user interface 1038, as shown in fig. 10H. As shown in fig. 10H, the user interface 1038 includes one or more options corresponding to different fuel types. For example, option 1040-1 corresponds to a gasoline fuel type and option 1040-3 corresponds to a mixed fuel type. In some embodiments, the options are scrollable to change the currently selected option. Thus, the user can select the fuel type or the power type for the user's vehicle. As will be described in detail below, in some embodiments, the fuel type of the vehicle may determine whether one or more sets of travel restriction rules are applicable to the vehicle. For example, a first rule set may be applied to an automobile having a gasoline fuel type, while a different rule set may be applied to an electric vehicle.

In fig. 10H, after option 1040-3 corresponding to the blended fuel type has been selected (e.g., and thus entry 1028 is filled with blended option 1042), the user receives user input 1003H selecting option 1044 to complete the process for adding the license plate to the map application. In some embodiments, in response to user input 1003h, device 500 displays user interface 1025, as shown in fig. 10I. In some embodiments, user interface 1025 includes entries 1026 and 1028 populated with user-provided values to confirm license plate and fuel type details. In fig. 10I, user input 1003I is received corresponding to confirmation of license plate and fuel type details. In some embodiments, in response to user input 1003i, device 500 adds a respective vehicle having a respective license plate and fuel type to the map application, and optionally provides a notification indication (e.g., pop-up window 1048), such as shown in fig. 10J. In some implementations, the device 500 displays a user interface 1000 corresponding to a map application. In some implementations, the pop-up window 1048 indicates that the vehicle has been successfully added to the map application. As shown in fig. 10J, the indication 1008 is no longer displayed in the user interface 1000. In some implementations, the indication 1008 is only displayed if the user has not previously added a license plate to the map application. Although the indication 1008 is no longer displayed in the user interface 1000, the user is optionally able to initiate a process of adding a license plate to a map application (e.g., adding another license plate) via a setup user interface for the map application (e.g., similar to user interfaces 848 and/or 862 described in connection with fig. 8I-8J). While the above disclosure describes a process for providing license plate information to a map application (e.g., adding license plates to the map application), it should be understood that the same or similar process may be performed to add other types of vehicle identifiers and/or vehicle characteristics to the map application.

In fig. 10K, when the currently active vehicle has a license plate "θb32f92", a user input 1003K (e.g., represented by an icon 1058 in the user interface 1000) requesting guidance directed to destination 1 is received. As described above in connection with methods 700 and 900, the user is able to select a currently selected vehicle from a list of vehicles. In some embodiments, characteristics of the currently selected vehicle are used to determine one or more suggested navigation routes, as described above in connection with methods 700 and 900.

In some embodiments, in response to user input 1003k corresponding to a request for a navigation route (e.g., directions), device 500 determines one or more suggested routes for the selected vehicle. In some embodiments, determining one or more proposed routes for the selected vehicle includes transmitting a route request to a navigation server or route server. In some implementations, the request for a route can include start location and destination location information. In some embodiments, the request for a route may include a license plate number of the vehicle for the requested route.

As described above, in some embodiments, certain geographic areas may have one or more travel limits. In some embodiments, the one or more travel limits are based on one or more characteristics of a vehicle attempting to travel within the restricted area. The examples described herein illustrate using the value of a vehicle license plate to define a travel limit for whether a vehicle is prohibited from traveling within a restricted area during a restricted period of time (although it is understood that other types of travel limits are possible). However, it should be understood that although the examples shown herein are based on the license plate of the vehicle, the restrictions may be based on any characteristic of the vehicle or any identifier, and the device 500 may determine one or more routes and/or perform the anonymization process described below.

However, it may be desirable to avoid transmitting the user's vehicle identifier information (e.g., license plate number) out of the device 500 (e.g., to a navigation server). In some embodiments, avoiding transmission of the user's vehicle identifier information advantageously protects the user's privacy by not transmitting identification information outside of the device 500 and not transmitting the user's travel history or destination history outside of the device 500. Thus, in some embodiments, the device 500 anonymously processes the user's vehicle identifier to generate an anonymous vehicle identifier that is transmitted to the navigation server, and maintains the user's actual vehicle identifier information within the device 500.

FIG. 10L illustrates an exemplary method 1060 for anonymously processing license plates. At step 1064, the electronic device (e.g., device 500) receives the travel limit rule set 1062 and determines portions of the license plate that are related to the respective travel limits based on the travel limit rule set 1062. In some embodiments, the travel limit rule set 1062 is a simplified rule set generated from a complete rule set (e.g., as will be described in detail below in connection with fig. 10N-10O). In some embodiments, the travel limit rule set 1062 is a signed and encrypted packet, as will be described in more detail below in connection with fig. 10N-10O. In some embodiments, the set of travel limit rules 1062 includes one or more rules defining which license plates are prohibited from traveling in the restricted area and which license plates are not prohibited from traveling in the restricted area. For example, the set of travel restriction rules may include rules indicating that odd license plates are prohibited from traveling in the restricted area and even license plates are not prohibited from traveling in the restricted area. In some embodiments, step 1064 determines that the respective portion of the license plate is associated with a respective travel limit if the respective portion of the license plate may affect a determination of whether the vehicle is prohibited from traveling in the restricted area. In some embodiments, if one rule in the set of travel restriction rules 1062 defines two different sets of values for respective portions of the license plate (optionally, without indicating whether the sets are prohibited from traveling in the restricted area), step 1064 determines that the respective portions of the license plate are associated with respective travel restrictions. For example, if the corresponding rule indicates that the odd license plate is disabled and the even license plate is not disabled, then at step 1064 the electronic device may determine that the last bit of the license plate is relevant (e.g., and optionally, if there are no other rules in the travel limit rule set 1062, then the other bits are not relevant). In another example, if the corresponding rule asks whether the last bit of the license plate falls within the first set of values that includes only even values or the second set of values that includes only odd values, then at step 1064 the electronic device may determine that the last bit of the license plate is relevant (e.g., and optionally, if there are no other rules in the travel limit rule set 1062, then the other bits are irrelevant).

In some embodiments, based on the determination from step 1064, the method 1060 processes the relevant portion of the license plate separately from the irrelevant portion of the license plate. For example, relevant portion 1068 is processed at step 1072 and irrelevant portion 1070 is processed at step 1074. At step 1072, the electronic device determines a set of valid values for a corresponding portion of the license plate within the same set as the user's actual license plate. For example, if the corresponding rule indicates that the first set for the last bit of the license plate includes only an even number and the second set includes only an odd number, then at step 1072 the device may determine whether the last bit of the user license plate is even or odd. If the last bit is even, the device optionally determines that the last bit of the user 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. On the other hand, if the last bit of the user's actual license plate is odd, the device optionally determines that the last bit of the user's license plate is within the "odd" group and that the value set comprising the user's actual license plate consists of odd values.

Based on this determination, at step 1076, the device can determine that to maintain the same type of restriction, the device should select one value from a corresponding set of values that includes the corresponding number of bits in the user's actual license plate. Thus, at step 1076, the electronic device selects one value from the respective set of values including the value of the respective number of bits in the user's actual license plate. For example, if the last bit of the user's actual license plate is an odd number, the device optionally selects an odd value for the last bit of the anonymous license plate. On the other hand, if the last bit of the user's actual license plate is even, the device optionally selects an even value for the last bit of the anonymous license plate. In some embodiments, the selection is performed randomly (e.g., one value is randomly selected from a set of values). In some embodiments, the selected value is different from the original value of the corresponding portion of the actual license plate. In some embodiments, the selected value is the same as the original value of the corresponding portion of the actual license plate (e.g., if the set of values includes only one value, then the actual value of the corresponding portion of the actual license plate). In some embodiments, step 1076 is performed on each relevant portion of the license plate.

At step 1074, the value of the irrelevant portion 1070 of the license plate is selected. In some embodiments, because the rules indicate that the irrelevant sections 1070 of the license plate are not divided into different sets of values, the electronic device is able to select among all valid values for the corresponding sections of the license plate. Thus, the device need not determine a plurality of different sets of values (e.g., as those done to the relevant portion 1068 at step 1072) in which to select. Thus, the value set from which to choose includes all valid values for the corresponding portion of the license plate. In some embodiments, the electronic device need only select from a set of valid values, regardless of whether the values are within any particular set of values. Thus, at step 1074, the device optionally selects randomly among all possible valid values. In some embodiments, the selected value is different from the original value of the corresponding portion of the actual license plate. In some embodiments, the selected value is the same as the original value of the corresponding portion of the actual license plate. In some embodiments, step 1074 is performed on each portion of the license plate that is not relevant to the restriction.

At step 1078, after the values for all portions of the license plate have been selected (e.g., via steps 1072 and 1076 or via step 1074), the electronic device optionally generates an anonymous license plate by merging the selected values into a single anonymous license plate. In some embodiments, when a user requests navigation of a route, an anonymous license plate is transmitted to the route or navigation server.

In some embodiments, the above-described method 1060 is performed in response to a request for a navigation route. For example, method 1060 is performed each time a user requests a route, and anonymous license plates are discarded after the request is completed. In some embodiments, method 1060 is performed periodically (e.g., daily, every 30 days, annually, etc.). In some embodiments, method 1060 is performed each time an electronic device receives a rule set (e.g., from a rule server, from a navigation server, etc.). In some embodiments, method 1060 is performed each time the electronic device determines that the rule set has changed.

FIG. 10M illustrates an example method of generating anonymous license plates using an example set of travel restriction rules. In FIG. 10M, the set of travel limit rules 1062 includes a first rule asking if the last digit of the license plate is 3 or 8, and a second rule asking if the second digit of the license plate is a letter in the A-F or O-T range. As shown in fig. 10M, neither the first rule nor the second rule defines whether the indicated specific value causes travel inhibition or does not cause travel inhibition.

At step 1064, the electronic device determines that the relevant portion 1068 of the license plate includes a second bit and a last bit according to the first rule and the second rule. As shown, because the first rule asks whether the last bit is 3 or 8, the electronic device can determine that the value of the last bit of the license plate is a factor in determining whether the vehicle is prohibited from traveling in the restricted area. Thus, the electronic device optionally determines that the last bit is associated with a travel limit. Similarly, because the second rule asks whether the second bit is within the range of A-F or O-T, the electronic device can determine that the value of the second bit of the license plate is a factor in determining whether the vehicle is prohibited from traveling in the restricted area. Thus, the electronic device optionally determines that the second bit is associated with a travel limit. As shown in fig. 10M, the relevant portion 1068 includes the second bit of the license plate and the last bit of the license plate.

In addition, at step 1064, because the travel limit rule set 1062 does not include rules other than the first rule or the second rule, the travel limit rule set 1062 does not care about the values of the first bit and the third bit to the sixth bit of the license plate. Thus, the electronic device optionally determines that the uncorrelated portion 1070 includes the first and third through sixth bits of the license plate.

At step 1072, the electronic device determines a value set in which to select a value for the anonymous license plate. In the embodiment shown in fig. 10M, because the second rule asks whether the second bit is within the range of a-F or O-T, the electronic device optionally determines that the value of the second bit is organized into two sets: a first set comprising values a-F and O-T (e.g., a set of values that fall "within" the second rule), and a second set comprising values G-M and U-Z (e.g., a set of values that fall "outside" the second rule). In the example shown in fig. 10M, only the letters are valid values of the second bit. After determining the value set of the second rule, the electronic device determines which of the value sets is the value set for selecting the anonymous license plate. As described above, to maintain the same limitations as the actual license plate, the electronic device selects from a set of values that includes the actual values of the corresponding portions of the actual license plate. Thus, because the second digit of the actual license plate is "B", the value of the second digit of the actual license plate falls "within" the second rule. Thus, the electronic device determines from 1080 that the set of values to be selected for the second bit is a set of values (e.g., a set including values A-F and O-T) that fall "within" the second rule.

Similarly, because the first rule asks whether the last bit is 3 or 8, the electronic device optionally determines that the value of the last bit is organized into two sets: a first set comprising values 3 and 8 (e.g., a set of values that fall "within" the first rule), and a second set comprising values 0-2, 4-7, and 9 (e.g., a set of values that fall "outside" the first rule). After determining the value set of the first rule, the electronic device determines which of the value sets is the value set for selecting the anonymous license plate. As described above, to maintain the same limitations as the actual license plate, the electronic device selects from a set of values that includes the actual values of the corresponding portions of the actual license plate. Thus, because the last bit of the actual license plate is "2", the value of the last bit of the actual license plate falls "outside" the first rule. Thus, the electronic device determines that the value set to be selected from 1080 for the last bit is a value set that falls "outside" the first rule (e.g., a set comprising values 0-2, 4-7, and 9).

At step 1076, after determining the set of values to select among them, the electronic device selects (optionally randomly) one value from the respective set. In FIG. 10M, for the second bit, the electronic device selects "Q"1084-1 from the set of values that includes A-F and O-T. Thus, the selected value of the second digit is considered to be the same as the actual value of the second digit of the actual license plate, thereby maintaining the same restriction state as the actual license plate, while hiding the actual value of the second digit of the user's actual license plate. In FIG. 10M, with respect to the last bit, the electronic device selects "6"1084-2 from the set of values that includes 0-2, 4, 7, and 9. Thus, the selected value of the last bit is considered to be the same as the actual value of the last bit of the actual license plate, thereby maintaining the same constraint as the actual license plate while hiding the actual value of the last bit of the user's actual license plate.

At step 1074, the electronic device selects an irrelevant portion of the license plate from the set of all valid values. For example, the electronic device selects from a set of all valid values for the first, third, fourth, fifth, and sixth bits of the license plate. In fig. 10M, the electronic device selects "θ" for the first bit, selects "G" for the third bit, selects "6" for the fourth bit, and selects "Y" for the fifth bit. In some embodiments, the selection is a random selection from among the valid values. Thus, as shown in fig. 10M, selecting a random value for a respective bit may result in selecting the same value (e.g., the first bit remains the same), or may result in selecting a letter when the original value is a letter (e.g., when the original value of the third bit is "3", the selected value of the third bit is "G", assuming, for example, that both the letter and the number are valid values of the third bit), and vice versa.

After performing step 1074 and/or step 1076 and selecting anonymous values for all portions of the license plate (e.g., for all bits of the license plate), at step 1078, the electronic device merges all anonymous values into a single anonymous license plate. For example, the first bit of the anonymous license plate is "θ" (e.g., selected in step 1074), the second bit is "Q" (e.g., selected in step 1076), the third bit is "G" (e.g., selected in step 1074), the fourth bit is "6" (e.g., selected in step 1074), the fifth bit is "2" (e.g., selected in step 1074), the sixth bit is "Y" (e.g., selected in step 1074), and the last bit is "6" (e.g., selected in step 1076), resulting in a complete anonymous license plate 1086 of "θqg62y6". As shown, the anonymous license plate is able to protect the original value of the user license plate ("θb32f92") while maintaining the same restriction state as the original value of the user license plate (e.g., to be treated by the navigation server as the same as the user's actual license plate). Thus, providing an anonymous license plate to a navigation server when requesting a navigation route will generate the same set of routes as the user's actual license plate provided by the electronic device, while maintaining the privacy of the user.

FIG. 10N illustrates an exemplary method 1090 of validating a set of travel limit rules. In some embodiments, method 1090 is performed at a server, such as a rule validation server. As will be described in detail below in connection with fig. 10O, the rule verification server is optionally a server that receives a rule set, determines whether the rule meets or violates a particular condition, and signs and/or encrypts the rule if the rule is verified. In some embodiments, validating the travel limit rule set includes determining whether the travel limit rule set violates certain conditions (e.g., or whether the travel limit rule set meets certain conditions). In some embodiments, at step 1094, the rule validation server receives the complete travel limit rule set 1092 and determines whether the rule set violates a privacy condition. In some embodiments, the complete set of travel restriction rules 1092 includes one or more rules defining a set of vehicles that are prohibited from traveling in the restricted area and a set of vehicles that are not prohibited from traveling in the restricted area. In some embodiments, the complete set of travel limit rules 1092 includes an indication of whether the respective set of values is prohibited from traveling in the restricted area and whether the respective second set of values is not prohibited from traveling in the restricted area. In some embodiments, the complete travel limit rule set 1092 optionally includes more information (e.g., more definitions, more rules, etc.) than a simplified travel limit rule set (e.g., such as travel limit rule set 1062 described above in connection with fig. 10L-10M).

In some embodiments, step 1094 includes step 1096 and step 1098. For example, determining whether the complete set of travel limit rules 1092 violates the privacy condition includes determining relevant portions of the license plate to which the rules relate (step 1096) and determining whether there are more than a threshold number of relevant portions (step 1098). In some embodiments, at step 1096, the rule validation server determines a portion of the license plate associated with the restricted area from the complete set of travel restriction rules 1092. In some embodiments, the determination of relevant portions is similar to the process described above in connection with step 1072, the details of which will not be repeated here for the sake of brevity. At step 1098, after determining the portion of the license plate that is associated with the restricted area, the verification server determines whether there are more than a threshold number of portions that are associated with the restricted area. If there are more than a threshold number of parts, the privacy condition is optionally violated, and if there are less than a threshold number of parts, the privacy condition is optionally not violated. In some embodiments, the threshold number of portions is one third of the number of license plate digits, one half of the number of digits, two thirds of the number of digits, three quarters of the number of digits, all bits, and the like. For example, in the example shown in fig. 10M where the license plate has seven digits, if the verification server determines that the complete set of travel restriction rules 1092 indicates that all seven digits of the license plate are associated with a travel restriction, then the privacy conditions are optionally violated. In such examples, if the set of travel limit rules indicate that all bits are relevant, there is a risk that user privacy will be violated. For example, the anonymization process described above may not be able to anonymously process the user license plate sufficiently to ensure that the identity of the user is not compromised and/or the privacy of the user is not violated. In some embodiments, if the set of travel limit rules indicates that all bits are relevant, it may indicate that the set of travel limit rules has been maliciously altered by an unverified entity. For example, the set of travel limit rules may have a flaw due to a transmission error, or the set of travel limit rules may have been hacked such that the device transmits the user's complete license plate to an unverified entity (e.g., a malicious entity). In such a scenario, it is desirable to reject the complete set of travel limit rules and prevent the electronic device (such as device 500, for example) from anonymously or otherwise transmitting the license plate outside the electronic device.

In some embodiments, the authentication server may perform privacy authentication steps that are different from the steps shown in method 1090. For example, the validation server may determine whether the rule defines a set of values for respective portions of the license plate having a valid value less than a threshold number. For example, if the corresponding rule defines a set of values to include only one value, the electronic device will not be able to properly anonymously process the user's license plate when performing the anonymization process. For example, if the rule set indicates that two-thirds of the number of license plates are related and that each value set includes only one value for each of these bits, the anonymization process described above will result in two-thirds of the number of bits having exactly the same value. Thus, the result will be an anonymous license plate that is substantially identical to the original license plate, so that user privacy will be violated. Thus, in some embodiments, the rule validation server may determine that the complete set of travel limit rules 1092 violate the privacy conditions.

Returning to step 1098, if the rule validation server determines that there are more than a threshold number of relevant portions (e.g., the "yes" branch), the privacy condition is violated, but if there are no more than a threshold number of relevant portions (e.g., the "no" branch), the privacy condition is not violated. In some embodiments, if the privacy conditions are violated, at step 1099, the rule validation server denies the complete travel limit rule set 1092. In some embodiments, rejecting the complete set of travel limit rules 1092 includes discarding the complete set of travel limit rules 1092, discarding the generation of a reduced set of travel limit rules from the complete set of travel limit rules 1092, and/or discarding the signing and/or encryption of the complete or reduced set of travel limit rules. In some embodiments, if the travel limit rule set is not verified (e.g., rejected), devices that rely on receiving the verified rule set (e.g., electronic devices such as those described in fig. 10L-10M) cannot anonymously process the user's license plate. In such embodiments, the electronic device optionally foregoes anonymously processing the user's license plate and foregoes providing the user with a customized navigation route. For example, the electronic device optionally provides only non-customized suggested routes (e.g., regardless of whether the travel limit applies to the user vehicle), such as described above in connection with fig. 6X.

At step 1907, if the privacy conditions are not violated, the rule validation server accepts the rule set. In some embodiments, accepting the rule set includes generating a reduced rule set based on the complete rule set. In some embodiments, the reduced rule set defines a set of values that are treated differently for the relevant portion of the license plate, similar to the travel limit rule set 1062 described above in connection with fig. 10L-10M. In some embodiments, after accepting the rule set and/or generating the reduced rule set, the rule validation server signs the reduced rule set at step 1095. In some embodiments, signing the reduced rule set includes encrypting the reduced rule set using a private key of the rule validation server. In some embodiments, when the encrypted reduced rule set is received by an electronic device (e.g., such as device 500), the electronic device can decrypt the reduced rule set using the public key of the rule verification server. In some embodiments, successfully decrypting the reduced rule set using the public key of the rule-verifying server indicates that the rules are authentic and that they have been verified by the rule-verifying server (e.g., so that it can be securely used with anonymous license plates to generate custom routes).

FIG. 10O illustrates an exemplary block diagram of an ecosystem 1093, including servers and/or devices and their interactions during the process of verifying rules, generating anonymous license plates, and providing navigation routes. In some embodiments, ecosystem 1093 includes a rules server 1091, a validation server 1087 (e.g., a rules validation server), a navigation server 1083 (e.g., a route server), and a client electronic device 1081 (e.g., device 500). It should be appreciated that any of the servers shown herein may be combined into a single server.

In some embodiments, rule server 1091 is a rule base server in which a complete set of travel limit rules 1089 is maintained and/or stored. In some embodiments, in response to a request for complete travel limit rule set 1089, rule server 1091 transmits complete travel limit rule set 1089 to validation server 1087. In some embodiments, validation server 1087 periodically (e.g., daily, every 15 days, every 30 days, every 3 months, every 6 months, etc.) issues requests for complete travel limit rule set 1089. In some embodiments, rule server 1091 automatically pushes full travel limit rule set 1089 to validation server 1087. In some embodiments, in response to receiving complete travel limit rule set 1089, verification server 1087 verifies complete travel limit rule set 1089 and generates signed reduced rule set 1085 (e.g., such as via method 1090 described above in connection with fig. 10N).

In some embodiments, the signed reduced rule set 1085 is transmitted to the navigation server 1083. In some embodiments, the navigation server 1083 stores and/or maintains the signed reduced rule set 1085 and transmits the signed reduced rule set 1085 (e.g., unmodified) to the client electronic device 1081 (e.g., optionally in response to a request from the client electronic device 1081 for the signed reduced rule set 1085). In some implementations, the client electronic device 1081 periodically (e.g., daily, every 15 days, every 30 days, every 3 months, every 6 months, etc.) issues a request for the signed reduced rule set 1085. In some implementations, the client electronic device 1081 issues a request for the signed reduced rule set 1085 in response to a request from a user to suggest a navigation route. In some implementations, in response to a request for a suggested navigation route, the client electronic device 1081 sends a request for navigation directions (e.g., navigation routes) to the navigation server 1083. In some embodiments, the request for navigation guidance sent to the navigation server 1083 includes an anonymous license plate (e.g., an anonymous license plate generated via the method 1060 described above in connection with fig. 10L-10M). In some implementations, the navigation server 1083 generates one or more navigation routes using the received license plates (e.g., anonymous license plates). In some embodiments, the navigation server 1083 may access the complete set of travel limit rules 1089 (e.g., the navigation server 1083 receives the complete set of travel limit rules 1089 from the rules server 1091) and is able to determine whether the received license plate is prohibited from traveling in the restricted area. In some embodiments, if the received license plate is prohibited from traveling in the restricted area, the navigation server 1083 optionally provides only the client electronic device 1083 with a navigation route that avoids the restricted area. In some implementations, the navigation server 1083 provides routes that avoid the restricted area and routes that do not avoid the restricted area (optionally with an indication provided to the navigation server 1083 that the license plate is prohibited from traveling along routes that do not avoid the restricted area). In some embodiments, navigation server 1083 considers time windows for restrictions in the set of travel restriction rules. For example, if the corresponding travel limit is applied only during business hours of a business day (e.g., from Monday to Friday 8:00 A.M. to 5:00 A.M.), the navigation server 1083 provides a route that avoids the restricted area only if a route request is received during business hours (e.g., assuming the vehicle is prohibited). In some implementations, the route request received from the client electronic device 1083 indicates a time at which the vehicle is scheduled to travel, and the navigation server 1083 is capable of determining whether the provided license plate is limited during the scheduled travel time and providing the navigation route accordingly.

Fig. 10P illustrates an apparatus 500 that displays one or more proposed routes received from a navigation server (e.g., such as navigation server 1083). As shown in fig. 10P, the currently selected vehicle has a license plate number "θb32f92", but an anonymous license plate number "θqg62y6" has been generated, which is provided to the navigation server to generate the customized route. As shown in fig. 10P, the apparatus 500 displays suggested routes 1071-1 and 1071-2. In some implementations, the proposed route 1071-1 is selected to avoid the travel limit because the navigation server has determined that the user's license plate is prohibited from traveling in the restricted area. In some embodiments, the proposed route 1071-2 is selected without consideration of travel limits. In some embodiments, the device 500 receives the proposed route 1071-2 from the navigation server as part of an initial request for guidance (e.g., including an anonymous license plate) or as part of a separate request for guidance (e.g., not including any license plate information, or including a second anonymous license plate selected to not be prohibited from traveling in the restricted area). Thus, as shown in fig. 10P, the device 500 is capable of anonymously processing a user's license plate, transmitting the anonymous license plate to a navigation server, receiving one or more navigation routes from the navigation server that avoid a restricted area (e.g., if the user is barred), and displaying the one or more navigation routes for viewing and selection by the user.

Fig. 11 is a flow chart illustrating a method 1100 of anonymously processing a vehicle identifier according to some embodiments of the present disclosure. Method 1100 is optionally performed on an electronic device (such as device 100, device 300, and device 500), as described above with reference to fig. 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.

As described below, method 1100 provides a way to anonymously process a vehicle identifier. The method ensures that personal information of a user is protected and cognitive burden of the user is reduced when interacting with the device user interface of the present disclosure, thereby creating a more efficient human-machine interface. For battery-operated electronic devices, improving the efficiency of user interaction with the user interface saves power and increases the time between battery charges.

In some embodiments, an electronic device 500 (e.g., a mobile device (e.g., a tablet, a smart phone, a media player, or a wearable device)) or a computer, optionally with a mouse (e.g., external), a track pad (optionally integrated or external), a touch pad (optionally integrated or external), a 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., receives (1102) a rule set associated with a travel limit for a geographic area via a communication device (e.g., a communication subsystem, a wired or wireless communication subsystem, such as WiFi, ethernet, NFC, etc.), such as a travel limit rule set 1062 in fig. 10L (e.g., a rule set defining which automobiles are prohibited from traveling in the geographic area and/or which automobiles are not prohibited from traveling in the geographic area).

In some implementations, the rule set is received from an external source (e.g., navigation server, rule server, etc.). In some embodiments, the rule set is a reduced rule set that indicates which bits of the license plate are related and defines a set of values for the related bits, optionally without defining whether a vehicle having the corresponding set of values is prohibited from traveling in a restricted area (e.g., without defining the consequences or results of the set of values). For example, the reduced rule set may indicate that the last bit is related to a travel limit (e.g., because the value of the last bit determines whether the car is prohibited) and that a car with an even last bit is treated differently than a car with a last bit that is odd. In some embodiments, the reduced rule indicates that cars whose last bit is even or odd are disabled or not disabled (e.g., the result or outcome of a rule-defined value set). In some embodiments, the simplification rules only indicate that even cars are in one group and odd cars are in another group. Both embodiments are contemplated and may be processed by the methods described herein. In some embodiments, the reduced rule set may indicate that certain rules apply during certain time periods and not during other time periods (e.g., rules apply during business hours on monday through friday, but not outside of these time periods). In some implementations, there may be multiple rules and/or nestable rules (e.g., the result of one rule may determine whether to apply a second rule, etc.). In some embodiments, the reduced rule set is reduced from the complete rule set. In some embodiments, the complete rule set is reduced by a server (e.g., navigation server, rule server, etc.) to a reduced rule set before transmitting the rules to the electronic device. In some embodiments, the rule is received in response to a request by the electronic device. In some implementations, the rules are received when a user requests a navigation route. In some embodiments, the rules are received from the server periodically (e.g., every 30 minutes, every hour, every 12 hours, every day, weekly, monthly, etc.).

In some embodiments, the electronic device uses the rule set to determine (1104), such as at step 1064 in fig. 10L, one or more first portions (1106) of identifiers of vehicles associated with the travel limit, such as associated portions 1068 in fig. 10L and 10M (e.g., determine bits associated with the travel limit), wherein the vehicle identifiers are stored on the electronic device and the one or more first portions of identifiers are populated with one or more first values (e.g., vehicle license plate information is stored on the electronic device).

In some embodiments, the relevant bit is a determined bit whose value may affect whether the corresponding vehicle is disabled. In the example given above in which the last bit is even and the vehicle is not prohibited, the device can determine from the rule that the last bit of the license plate is associated with a travel limit because the value of the last bit indicates whether the corresponding vehicle is prohibited from traveling in the restricted area. In some implementations, multiple bits may be determined to be related. For example, if the rule set includes a first rule asking if the last bit is even or odd and a second rule asking if the first bit is between A-M or N-Z, then both the first bit and the last bit of the license plate are related. In some embodiments, the vehicle license plate information is provided by a user. In some embodiments, the vehicle license plate information is automatically populated with information received from an external source, such as via the methods described above in connection with method 900.

In some embodiments, the electronic device uses the rule set to determine one or more second portions of the vehicle identifier that are not related to the travel limit (1108), such as the irrelevant portion 1070 in fig. 10L and 10M (e.g., determine bits that are not related to the travel limit). In some embodiments, the bits that are not related to the travel limit are determined bits that do not affect whether the corresponding vehicle is disabled. For example, if a unique rule in the rule set asks whether the last bit is even or odd, then all other bits in the vehicle license plate are not relevant to the travel limit. In another example, if the rule set includes a first rule asking if the last bit is even or odd and a second rule asking if the first bit is between A-M or N-Z, then bits of the vehicle license plate other than the first bit and the last bit are not related to the travel limit.

In some embodiments, the electronic device generates (1110) an anonymous identifier corresponding to a vehicle identifier, such as anonymous license plate "θqg62y6" in fig. 10M (e.g., for protecting a user's actual license plate from travel restrictions issued from the device, generating a license plate that is a proxy for the actual license plate) based on a determination of relevant and irrelevant bits, wherein the anonymous 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 anonymous license plate has bits corresponding to the determined relevant portions of the license plate and bits corresponding to the determined irrelevant portions of the license plate).

In some embodiments, the anonymous identifier is generated each time the user requests a navigation route (and optionally discarded after the request is completed). In some embodiments, the anonymous identifier is generated each time the device receives a set of travel limit rules. In some embodiments, the anonymous identifier is generated each time the device receives an updated set of travel limit rules (e.g., based on a determination that the set of travel limit rules has changed).

In some embodiments, generating the anonymous identifier includes selecting, for the one or more third portions, values selected from a first set of values corresponding to the one or more first values based on a rule set, wherein the first set of values is a subset of a valid set of 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 selecting "6" from the set of values including 0-2, 4-7, and 9 in step 1076 of fig. 10M (e.g., selecting one value from the set of values in the same group as the actual value of the respective license plate for bits that have been determined to be related to the travel limit).

For example, if the rule asks whether the last bit is even or odd, then if the last bit of the user's actual license plate is odd, the device selects the odd as a proxy for the actual value of the last bit of the user's license plate. In some embodiments, selecting a value from the same group as the user's actual value enables the device to ensure that the anonymous license plate remains subject to the same limitations as the user's actual license plate. In some embodiments, the selected value is a value that is different from the actual value of the corresponding bit of the user license plate. In some embodiments, the selected value is the same value as the actual value of the corresponding bit of the user license plate.

In some embodiments, generating the anonymous identifier includes selecting a random value (1114) for the one or more fourth portions from a set of valid values for the one or more fourth portions, such as selecting values "θ", "G", "6", "2", and "Y" from a set of all valid values at step 1074 of fig. 10M (e.g., for a bit that has been determined to be irrelevant to a driving restriction, selecting a value (for a corresponding bit) from all valid license plate values).

In some embodiments, selecting the value includes randomly selecting a value from all valid license plate values. In some implementations, the valid value sets for the respective bits are received from an external source (e.g., navigation server, rules server, etc.). In some embodiments, the selected value is a value that is different from the actual value of the corresponding bit of the user license plate. In some embodiments, the selected value is the same value as the actual value of the corresponding bit of the user license plate. In some embodiments, after selecting values for the one or more third portions and the one or more fourth portions, an anonymous license plate is generated by combining the selected sets of values into a single license plate. In some embodiments, the anonymous license plate has the same restriction status as the original license plate. For example, if the original license plate is prohibited from traveling within the restricted area, the anonymous license plate is also prohibited from traveling within the restricted area (and vice versa). Thus, the anonymous license plate has the same restriction status as the actual license plate. In some implementations, ensuring that the anonymous license plate has the same restriction status as the actual license plate ensures that the anonymous license plate is similarly treated as the actual license plate when requesting a navigation route from the navigation server. For example, if the navigation server receives a license plate with a navigation route request and determines an available route for the vehicle based on whether the license plate is prohibited from leaving the restricted area, providing an anonymous license plate that is also prohibited from traveling in the restricted area to the navigation server (e.g., if the actual license plate is prohibited from leaving the restricted area) ensures that the navigation server provides the same or similar navigation route as if the device had provided the actual license plate of the vehicle, without requiring the device to transmit the user's actual license plate from the device.

In some embodiments, the electronic device transmits (1116) the anonymous identifier via the communication device to a route server for generating a travel route in the geographic area, wherein the vehicle identifier is not transmitted to a destination external to the electronic device, including the route server, such as navigation guidance request 1077 in fig. 10O (e.g., transmitting the anonymous license plate to the route server that determines routes available to the respective vehicle based on the provided license plate).

In some implementations, the anonymous identifier is transmitted with a request to provide a route from a first geographic location to a second geographic location. Thus, in some embodiments, after transmitting the anonymous identifier, the device receives one or more possible travel routes from the first geographic location to the second geographic location from the route server. In some embodiments, requesting a navigation route from a route server includes transmitting an anonymous license plate and origin and destination location information. In some implementations, in response to requesting a navigation route, the device receives one or more navigation routes from a navigation server (optionally based on whether the anonymous license plate is prohibited from traveling in the restricted area). In some embodiments, if the received identifier indicates that the user vehicle is prohibited from traveling in the restricted area, the route server may select one or more possible travel routes to avoid the corresponding travel limit. In some implementations, one or more travel routes received from the route server may be displayed in a map user interface, similar to that described above in connection with method 700. In some embodiments, the route server provides only routes that are not prohibited by the travel limit. Thus, in some embodiments, the device performs the above anonymization method twice: once a route for a restricted vehicle is generated (e.g., anonymous identifiers belonging to a set of identifiers that result in a route that avoids the restriction), and a route for an unrestricted vehicle is generated at a time (e.g., anonymous identifiers belonging to another set of identifiers that result in a route that ignores the restriction), the user is provided with the option to avoid the restriction or ignore the restriction, as described above in connection with method 700. In some embodiments, the anonymous identifier is generated each time the user requests a route that is affected by a travel limit. In some embodiments, the anonymous identifier is generated each time a new rule set is received (e.g., the device optionally determines whether the new rule set is different from the previous rule set and generates the new anonymous identifier accordingly). In some embodiments, the original license plate number of the vehicle is not transmitted from the electronic device as part of the process of determining the navigation route. In some embodiments, the original license plate number of the vehicle is never transmitted from the electronic device as part of any map or navigation process.

The above-described manner of requesting a route for a particular vehicle from a route server (e.g., by anonymously processing the vehicle's license plate based on a set of travel restriction rules and transmitting the anonymously license plate to the route server to generate a possible route) provides a quick and efficient way of obtaining an applicable travel route without compromising the privacy of the electronic device or the vehicle user, which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., by automatically anonymously processing the user license plate to protect user privacy, does not require the user to anonymously process the vehicle license plate manually, and then transmits to the route server), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the identifier of the vehicle is a license plate number of the vehicle, such as the license plate number "θb32f92" shown in fig. 10L (e.g., the corresponding travel limit is based on the license plate number of the vehicle). For example, if the set of travel restriction rules indicates that the vehicle is prohibited from traveling in the restricted area if the license plate of the vehicle matches a particular condition, and that the vehicle is not prohibited from traveling in the restricted area if the license plate of the vehicle does not match the condition. In some embodiments, the identifier may be other types of identifiers (e.g., unique or non-unique). For example, if the corresponding travel limit is based on the color of the vehicle, the identifier is the color of the vehicle. In another example, if the corresponding travel limit is based on the type of vehicle (e.g., car, SUV, truck, minivan, semi-trailer, etc.), the identifier is the type of vehicle. In some embodiments, the identifier includes a Vehicle Identification Number (VIN). In some embodiments, the identifier includes a fuel or power type of the vehicle (e.g., gasoline vehicle, hybrid vehicle, plug-in hybrid vehicle, electric vehicle, etc.).

The above-described manner of requesting a route for a particular vehicle from a route server (e.g., by anonymously processing the vehicle's license plate based on a set of travel restriction rules and transmitting the anonymously license plate to the route server to generate a possible route) provides a quick and efficient way of obtaining an applicable travel route without compromising the privacy of the electronic device or the vehicle user, which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., by automatically anonymously processing the user license plate to protect user privacy, does not require the user to anonymously process the vehicle license plate manually, and then transmits to the route server), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the electronic device determines that the respective portions of the one or more first portions cannot be changed, such as in step 1072 of fig. 10L (e.g., determines that the respective bits of the travel limit requirement license plate are not anonymously processed). In some embodiments, the respective bit of the license plate cannot be anonymously processed if the determined valid set of values for the respective bit includes only one value (e.g., the value of the respective bit of the actual license plate). For example, if the corresponding bit (e.g., the first bit) of the license plate is an indicator of the area to which the vehicle is registered, then a corresponding rule asking whether the vehicle is registered in the particular area results in a determination that the first bit of the license plate cannot be anonymously processed (e.g., if the first bit of the actual license plate indicates that the vehicle is indeed registered in the particular area).

In some embodiments, generating the anonymous identifier further includes selecting, for example, in step 1076 of fig. 10L, a value of a respective portion of the one or more first portions for a respective portion of the one or more third portions corresponding to the one or more first portions (e.g., if the driving constraint requires that the respective bit of the license plate not be anonymously processed or masked, the respective bit of the anonymous license plate has the same value as the original license plate).

For example, if the rule asks if the first bit is "A" and the first bit of the original license plate of the vehicle is "A", then the valid value set of the first bit includes only the value "A", so the resulting anonymous license plate has "A" as its first bit. Thus, in some embodiments, one or more of the license plates may have the same value as the original license plate according to rules in the set of travel limit rules. In some embodiments, other bits of the license plate that do not result in a valid set of values for only one value can be anonymously processed as described above (e.g., they optionally result in anonymized bits of a different value than the original license plate).

The above-described manner of anonymously processing the vehicle identifier (e.g., by selecting the same value as the original license plate if the travel limit requires that the corresponding bit not be changed) provides a quick and efficient way of obtaining an applicable travel route without compromising the privacy of the electronic device or vehicle user (e.g., by maintaining the same limit state as the original license plate, including maintaining the same value of the corresponding bit of the license plate if the travel limit requires), which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., by automatically anonymously processing the user license plate to protect user privacy, does not require the user to manually anonymously process the vehicle license plate, and then transmits to the route server), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the rule set includes a first rule defining a first set of values for a first respective portion of the identifier (e.g., the first rule defining a first set of values for a respective portion of the identifier having a first travel limit result (e.g., a respective bit of a license plate) and a second set of values for the first respective portion of the identifier that are different than the first set of values, such as the first rule in travel limit rule set 1062 in fig. 10M defining a first set of values including "3" and "8" and a second set of values including 0-2, 4-7, and 9 (e.g., the first rule defining a second set of values for a respective portion of the identifier having a second travel limit result (e.g., a respective bit of a license plate) that is different than the first travel limit result).

In some embodiments, the first rule defines a first set of values that inhibit travel. In some embodiments, the rule set does not indicate whether the first value set results in a prohibition. In some embodiments, the rule set indicates that the first value set is present and optionally treated differently than the second value set. In some embodiments, the first rule defines a second set of values that are not prohibited from traveling. In some embodiments, the rule set does not indicate whether the second value set results in a prohibition. In some embodiments, the rule set indicates that the second value set is present and optionally treated differently than the first value set.

In some embodiments, determining one or more first portions of the vehicle identifier that are associated with the travel limit using the rule set includes determining that the first rule defines a first value set and a second value set for a first respective portion of the identifier, such as step 1064 in fig. 10M (e.g., if the rule set includes a rule defining two valid value sets for respective bits of the license plate (optionally indicating that the two value sets are treated differently), the device determines that the respective bits of the license plate are associated with the travel limit). For example, because there are two sets of possible values for the respective bits of the license plate, and the two values are treated differently, the value of the respective bit provides information as to whether the respective license plate is disabled (e.g., the respective bit indicates the result or a factor that determines the result).

The above-described manner of determining relevant portions of an identifier (e.g., by determining whether one rule set defines two value sets for respective portions of the identifier that are treated differently) provides a quick and efficient manner of determining relevant portions of an identifier with a set of travel limit rules (e.g., by analyzing whether rules create different sets of values), which simplifies interactions between a user and an electronic device, enhances operability of the electronic device, and makes a user-device interface more efficient, which additionally reduces power usage and extends battery life of the electronic device by enabling a user to use the electronic device faster and more efficiently while reducing errors in device usage.

In some embodiments, receiving a rule set associated with a travel limit of a geographic area includes receiving rule sets from a rule verification server, such as signed reduced rule sets 1085 and 1079 in fig. 10O (e.g., the rule sets are verified (e.g., by the rule verification server) to determine whether the rule sets are authentic or whether the rule sets are likely to violate a user's privacy.

In some embodiments, if the validation server validates the rule set, the validation server generates one rule set to provide to the electronic device (e.g., by transmitting the rule set directly to the electronic device or transmitting the rule set to a navigation server, which then transmits the rule set to the electronic device). In some implementations, the rule set generated by the validation server is a signed (e.g., authenticated and/or encrypted) version of the initial rule set (e.g., rule set from the rule server). In some embodiments, the rule set generated by the validation server is a reduced rule set based on the initial rule set.

In some embodiments, the rule set is generated from a complete rule set associated with a travel limit of the geographic area, such as complete travel limit rule set 1089 in fig. 10O (e.g., the validation server receives the complete rule set from the rule server or any suitable rule repository), and indicates one or more portions of the vehicle identifier that are relevant to the travel limit and a valid value set for the one or more portions of the vehicle identifier, without indicating whether the vehicle identifier is limited by the travel limit (e.g., the value set defines a value set for a relevant portion of the license plate and a corresponding relevant portion).

In some embodiments, the complete rule set defines conditions under which the vehicle is prohibited from traveling in the restricted area. For example, the complete rule set may indicate that if the last number of license plates is even, the vehicle is prohibited from traveling in the restricted area, whereas if the last number of license plates is odd, the vehicle is not prohibited from traveling in the restricted area. In some embodiments, the validation server determines the bits of the license plate that are relevant to the travel limit and the bits of the license plate that are not relevant to the travel limit based on the complete rule set.

In some embodiments, the validation server determines a first set of values for respective relevant bits of license plates that are prohibited from traveling in the restricted area and a second set of values for respective relevant bits of license plates that are not prohibited from traveling in the restricted area based on the complete rule set. For example, if the complete rule set may indicate that the vehicle is prohibited from traveling in the restricted area if the last bit of the license plate is even, and that the vehicle is not prohibited from traveling in the restricted area if the last bit of the license plate is odd, the validation server generates a first value set comprising even values and a second value set comprising odd values. Thus, the first set of values (e.g., even values) includes values that inhibit travel, while the second set of values (e.g., odd values) includes values that do not inhibit travel. In some embodiments, the set of values includes only values that are valid for the corresponding bits of the license plate. For example, if the last digit of the license plate is only a number and not a letter, then the value set includes only a number and not a letter. In some embodiments, after determining the set of values, the validation server generates a reduced set of rules based on the complete set of rules. In some embodiments, the reduced rule set indicates which bits of the license plate are relevant (e.g., the last bit in the example provided above), as well as the value set determined above. In some embodiments, the reduced rule set does not indicate whether the corresponding value set is a disabled value or a non-disabled value (e.g., the reduced rule defines a group, but does not indicate whether the group is disabled or not disabled). In some embodiments, the reduced rule set does indicate whether the corresponding value set is a forbidden value or a non-forbidden value. In some embodiments, the reduced rule set is generated only after the verification server has determined that the complete rule set does not violate the privacy condition set, as will be described in detail below. In some embodiments, the verification server digitally signs the reduced rule set (e.g., optionally using a private key associated with the verification server) to authenticate that the reduced rule set originated from the verification server. In some embodiments, the signed and/or encrypted reduced rule set is then provided to the electronic device (e.g., optionally via a navigation server).

The above-described manner of receiving the reduced rule set (e.g., from a rule validation server that validates the rules and generates the reduced rule set from the complete rule set) provides a quick and efficient manner for reducing the rules to a set that is easy to use by the electronic device (e.g., by compiling only the information required to anonymously process license plates together), which simplifies interactions between the user and the electronic device, enhances operability of the electronic device, and makes the user-device interface more efficient (e.g., by pre-compiling the reduced rule set from the complete rule set and providing the reduced rule set to the client devices without requiring each client device to process the complete rule set), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

In some embodiments, the rule validation server determines whether the complete rule set meets one or more conditions, such as step 1094 in fig. 10N (e.g., the validation server determines whether the complete rule set is at risk of violating user privacy).

For example, if the complete rule set indicates that each bit is relevant, then the condition is optionally not satisfied, as selecting from the small value set for each bit may not be sufficient to anonymously process the user license plate. In another example, if the complete rule set results in a set of valid values for a threshold number of bits having a value less than the threshold number (e.g., 60%, 75%, 80%, 90% of bits have a set of values less than 2, 3, 4, etc. valid values), then the condition is optionally not met. In some embodiments, a complete rule set satisfies one or more conditions if the rule set does not risk violating user privacy. In some embodiments, the rule validation server determines whether the complete rule set is not authentic (e.g., if the complete rule set has an incorrect format, if the complete rule set is not signed authentically by the rule repository or rule server). Thus, in some embodiments, a complete rule set satisfies one or more conditions if it is not indicated that the complete rule set is not authentic.

In some embodiments, in accordance with a determination that the complete rule set satisfies one or more conditions, the rule-validating server signs the generated rule set for transmission to the electronic device, such as step 1095 in fig. 10N (e.g., the rule-validating server optionally digitally signs and/or encrypts the reduced rule set using a private key of the rule-validating server), wherein the electronic device is capable of decrypting the generated rule set (e.g., the client device can access a public key of the rule-validating server and is capable of decrypting the reduced rule set using the public key of the rule-validating server).

In some embodiments, successfully decrypting the reduced rule set indicates that the reduced rule set is authentic. In some embodiments, the decryption process may include a plurality of communication transactions (e.g., including generation and/or transmission of temporary session keys, etc.). In some embodiments, the signed reduced rule set is provided directly to the client electronic device. In some embodiments, the signed reduced rule set is provided to a navigation server (the navigation server then optionally provides the signed reduced rule to the client device).

In some embodiments, in accordance with a determination that the complete rule set does not satisfy the one or more conditions, the rule validation server foregoes signing the generated rule set, such as step 1099 in fig. 10N (e.g., if the complete rule set does not satisfy the one or more conditions, the complete rule set is not validated and is rejected by the rule validation server).

In some embodiments, the rule validation server does not generate a reduced rule set. In some embodiments, the rule validation server discards the reduced rule set without signing, encrypting, or otherwise transmitting the reduced rule set to the client device. In some embodiments, performing verification of the rule and signing the verified rule ensures that the rule provided to and received by the client device is trusted and does not violate any verification conditions. The process optionally also ensures that rules are not maliciously altered along the way. In some embodiments, the above-described verification method (e.g., additionally or alternatively verified by a rule verification server) is performed on the client device in response to receiving the rule set (e.g., a complete rule set or a reduced rule set).

The above-described manner of generating a reduced rule set (e.g., by determining whether a complete rule set violates or satisfies certain conditions, and then generating a reduced rule set and signing based on the complete rule set) provides a quick and efficient way of verifying travel limit rules, which simplifies interactions between users and electronic devices, enhances operability of the electronic devices, and makes the user-device interface more efficient (e.g., by automatically determining whether rules should be provided to client devices, thereby protecting the client devices from potentially malicious rules, without requiring each client device to separately determine whether the rules violate certain conditions), which additionally reduces power usage and extends battery life of the electronic devices by enabling users to more quickly and efficiently use the electronic devices while reducing errors in device usage.

In some embodiments, after transmitting the anonymous identifier to the route server, the electronic device receives one or more proposed routes based on the anonymous identifier, such as proposed route 1075 in fig. 10O, from the route server (e.g., an anonymous license plate is provided to the route server or navigation server for determining one or more navigation routes).

In some embodiments, the route server or navigation server may access the complete set of travel restriction rules and determine whether the user vehicle is prohibited from traveling within the restricted area based on the anonymous license plate. Based on the determination, the route server optionally determines routes that avoid the restricted area (e.g., if the anonymous license plate indicates that the user's vehicle is prohibited) and provides those routes to the electronic device. In some embodiments, the route server determines routes that do not avoid restrictions and will provide those routes to the electronic device, optionally with an indication that the user vehicle may be prohibited from traveling along the route. In some embodiments, the route server optionally determines that the user vehicle is not prohibited from traveling in the restricted area (e.g., if the anonymous license plate indicates that the user vehicle is not prohibited) and provides one or more routes selected without consideration of the restricted area (e.g., without explicit selection of avoiding the restricted area) to the electronic device. In some embodiments, if the user license plate is prohibited from traveling in the restricted area, the anonymizing process described above is performed multiple times to generate a first license plate that is prohibited from traveling in the restricted area to receive navigation routes that avoid the restricted area, and a second license plate that is not prohibited from traveling in the restricted area to receive navigation routes selected regardless of the restricted area. In some implementations, similar to the process described above in method 700, the electronic device displays routes that avoid the restricted area and routes that do not avoid the restricted area.

The above-described manner of generating a navigation route provides a quick and efficient way of generating a navigation route (e.g., by anonymously processing a user license plate and providing the anonymously license plate to a route server to generate a navigation route), which simplifies interactions between a user and an electronic device, enhances operability of the electronic device, and makes a user-device interface more efficient (e.g., by automatically anonymously processing a user license plate when requesting a navigation route to protect user privacy, does not require the user to manually anonymously process a vehicle license plate, and then re-transmits to the route server), which additionally reduces power usage and extends battery life of the electronic device by enabling the user to more quickly and efficiently use the electronic device while reducing errors in device usage.

It should be understood that the particular order in which the operations in fig. 11 are described is merely exemplary and is not intended to suggest that the described order is the only order in which the operations may be performed. Those of ordinary skill in the art will recognize a variety of ways to reorder the operations described herein. Additionally, it should be noted that the details of other processes described herein in connection with other methods described herein (e.g., methods 700, 900, and 1300) are likewise applicable in a similar manner to method 1100 described above in connection with fig. 11. For example, the operations of the electronic device anonymously processing the vehicle identifier described above with reference to method 1100 optionally have one or more of the characteristics described herein with reference to other methods described herein (e.g., methods 700, 900, and 1300) of displaying a customized navigation route, receiving information regarding the characteristics of the respective vehicle, valid route determination, etc. For the sake of brevity, these details are not repeated here.

The operations in the above-described information processing method are optionally implemented by running one or more functional modules in an information processing apparatus such as a general-purpose processor (e.g., as described with respect to fig. 1A-1B, 3, 5A-5B) or a dedicated chip. Furthermore, the operations described above with reference to fig. 11 are optionally implemented by the components depicted in fig. 1A-1B. For example, the receiving operation 1102, determining operation 1104, generating operation 1110, and transmitting operation 1116 are optionally implemented by the event sorter 170, the event recognizer 180, and the event handler 190. An event monitor 171 in the event sorter 170 detects a contact on the touch-sensitive surface 604 and an event dispatcher module 174 delivers event information to the application 136-1. The respective event identifier 180 of the application 136-1 compares the event information to the respective event definition 186 and determines whether the first contact at the first location on the touch-sensitive surface corresponds to a predefined event or sub-event, such as a selection of an object on the user interface. When a respective predefined event or sub-event is detected, the event recognizer 180 activates an event handler 190 associated with the detection of the event or sub-event. Event handler 190 optionally utilizes or invokes data updater 176 or object updater 177 to update the application internal state 192. In some embodiments, event handler 190 accesses a corresponding GUI updater 178 to update what is displayed by the application. Similarly, it will be apparent to one of ordinary skill in the art how other processes may be implemented based on the components depicted in fig. 1A-1B.

Routes based on initial state of charge and/or buffering

Users interact with electronic devices in many different ways, including using the electronic device to view directions from one geographic location to another. In some embodiments, different routes from one geographic location to another may be feasible (e.g., the state of charge and/or remaining range of the vehicle remains above zero throughout the route), depending on the initial state of charge and/or starting range of the vehicle (e.g., an electric or other vehicle). In some embodiments, different routes from one geographic location to another may be feasible, depending on the minimum state of charge and/or remaining range allowed (e.g., by the user) for the route from one geographic location to another. The embodiments described below provide a way to effectively identify a viable route for a vehicle based on different initial states of charge of the vehicle and/or based on a minimum expected buffered state of charge of the vehicle during the route.

Fig. 12A-12G illustrate exemplary ways to effectively identify a viable route for a vehicle based on different initial states of charge of the vehicle and/or based on a minimum expected buffered state of charge of the vehicle during the route, according to some embodiments of the present disclosure. The embodiments in these figures are used to illustrate the processes described below, including the processes described with reference to fig. 13. Although fig. 12A-12G illustrate various examples of the manner in which the processes described below with reference to fig. 13 are performed, it should be understood that these examples are not meant to be limiting and that one or more of the processes described below with reference to fig. 13 may be performed in a manner not explicitly described with reference to fig. 12A-12G.

In some embodiments, to determine various routes that meet one or more constraints (e.g., minimum state of charge along the route, etc.), it may be beneficial to use a graphical structure to represent possible routes from one location to another. For example, fig. 12A shows an exemplary graphical representation 1202A of a possible route or road network from an initial location (corresponding to node or vertex S1204 a) to a final location (corresponding to node or vertex T1204 f). In some embodiments, graph 1202a is a directed graph G= < V, E >, where V is a set of nodes or vertices, and E: V x V is a set of edges in graph 1202a (e.g., edges 1208a-1208E connecting nodes 1204a-1204 f). The edges 1208 are optionally associated with corresponding edge weighting functions d and c. The edge weighting function d for a given edge 1208 optionally corresponds to the time that the vehicle travels (and/or the time that it is required to travel) along the road segment corresponding to the route or road network of that edge 1208. The edge weighting function c for a given edge 1208 optionally corresponds to the energy consumed by the vehicle along the road segment corresponding to the route or road network for that edge 1208.

In some embodiments, the subset of nodes 1204 of the graph 1202a corresponds to locations along a road network that includes charging stations, which are optionally associated with a charging function. In some embodiments, those charging functions are concave charging functions cf: [0, m ], which map the time spent for the vehicle battery to reach a state of charge (SoC) and/or to charge at the corresponding charging station to the SoC of the battery after charging at the corresponding charging station. For example, in fig. 12A, node 1204b is associated with a charging station associated with charging function 1206a, and node 1204e is associated with a charging station associated with charging function 1206 b.

The shortest possible path through graph 1202a is optionally a path that minimizes the total travel time from node 1204a to node 1204f, including the charge time at node 1204b (if any) and at node 1204e (if any), while maintaining the battery SoC above zero at all points along the route, optionally except at the node associated with the charging station/function and/or end node 1204 f. Thus, in some embodiments, the shortest possible path depends on the structure of G, the edge weighting functions d and c, and/or the starting SoC of the vehicle battery at node S1204 a.

However, in some cases, the user may wish to determine the shortest possible path for a given starting SoC (e.g., assuming that the starting SoC at node 1204a is 10% or 20% or 30%, the user may request the shortest possible path from the first location to the second location). Additionally or alternatively, the user may wish to determine the shortest feasible path given the user-defined buffered SoC (e.g., the SoC of the battery does not drop below the user-defined buffered SoC, optionally except at the charging station and/or end node 1204 f). Determining solutions to the above-described problems may require exponential time, processing resources, and/or storage, and may result in poor performance, making real-time solutions (e.g., providing such routes in real-time in response to user input at a navigation application on a user device such as device 500) impractical or infeasible.

Some embodiments of the present disclosure relate to starting power mapping (SCM), and some embodiments of the present disclosure relate to Buffer Mapping (BM). The starting charge map is optionally a function SCM: [0 ], M]Such that for a given starting beta _s ∈[0,M](where M is the predetermined (e.g., maximum) state of charge of the vehicle battery) and given starting and ending positions, the SCM is evaluated to return to the corresponding shortest possible path between the starting and ending positions. The buffer map is optionally a function BM:0, M]So that for a given buffer SoCb e [0, M]The evaluation BM returns the shortest path on which the SoC does not drop below b, optionally except at the charging station and/or end node 1204 f.

As described above, in some embodiments, determining the SCM is similar to the shortest possible path problem unknown to the starting SoC. SCM as defined herein optionally has various use cases and/or benefits. For example, the density of SCMs may be used as an indicator of the sensitivity of the viable paths of the starting SoC. Furthermore, if the starting SoC is higher, SCM may be used to generate and/or recommend faster routes to the user. For example, given SCM, a suggestion is real-time feasible that it takes 45 minutes to generate an optimal path such as "get with your current SoC, but you can save 15 minutes during the journey if you charge more than 10 minutes at your current location before starting along the route. In addition, different trips taken by the user may be associated with different levels of risk avoidance, and the SCM may be used to generate and/or present the user with a viable path appropriate for the current scenario. For example, consider two possible travel scenarios: one through urban areas with high density of charging stations during the day and the second through sparsely populated areas after the night. In a first scenario, the driver may weigh in a shorter travel time a higher risk of stranding (e.g., battery depletion), while in a second scenario, a slower route with a lower risk of stranding may be the preferred choice. SCM may be used to provide such alternatives to the driver. Finally, in some implementations, the route is optionally calculated on a server, and then transmitted and presented to the user on the mobile client (e.g., device 500). In the case of an electric vehicle, because of the battery constraints applied, it is optionally necessary to transmit more information about the vehicle to a server than an Internal Combustion (IC) vehicle. If a route, the SCM is calculated at the server and transmitted to the client (e.g., device 500) for subsequent route display, eliminating the need to transmit the current SoC to the route server, which may better protect the privacy of the user. The client device will optionally use the SCM and the SoC itself (e.g., current SoC, user-defined starting SoC, etc.) to generate the route presented to the user.

In some embodiments, the SCM is determined using a Reverse Charge Function Propagation (RCFP) algorithm. The RCFP optionally operates on a reverse graph G' that is obtained by reversing the direction of edges in graph G (e.g., graph 1202 a). For example, FIG. 12B shows an exemplary reverse pattern 1202B corresponding to pattern 1202A in FIG. 12A. The inverted graphic 1202b optionally has the same nodes 1204 as the graphic 1202A in FIG. 12A, but has sides 1209a-1209e that are optionally inverted relative to side 1208 in FIG. 12A (e.g., side 1209a corresponds to side 1208a but is opposite; side 1209b corresponds to side 1208b but is opposite; etc.). RCFP optionally with residual SoC beta _t (e.g., the SoC of the vehicle battery upon reaching the final location on the route corresponding to node T1204 f) begins at node T1204 f and propagates toward node S1204 a. Beta _t Optionally an input to the algorithm. When RCFP reaches a given node v1204 in graph 1202b, a label l' =is optionally created and stored<τ _t ,β′ _u ,u,f _[v…u] >. In the tag, τ _t Optionally the total travel time on sub-path v … u, u optionally being the node associated with the last charging station encountered in the RCFP, β' _u Optionally is a SoC after charging at u, and f _[v…u] Optionally is the energy consumption profile of sub-path v … u. For example, in FIG. 12BThe sub-path v … u at node 1204b of (e.g., the node associated with the last charging station encountered from node T1204 f in the RCFP) is optionally a sub-path from node 1204b to node 1204 e. In RCFP, β 'can be determined for a given node 1204' _u Because RCFP is a reverse search, and because the energy consumption between a given node 1204 and a target node is known, travelling from the last charging station to, for example, node T1204 f while remaining beta _t The amount of power required to reach node T1204 f is also known.

In some embodiments, the energy consumption profile for a given path P is a function f (P): [0, M]→[-M，M]U { infinity }, the function will start SoC beta of the path _s Final SoC beta mapped to path after traversing path P _t . f (P) optionally uses 3-tuple<in _P ，cost _P ，out _P >Performing a calculation in which _P Optionally the minimum SoC required to traverse P at s,

and out _p Optionally the largest SoC possible at t after traversing P. In some embodiments, f (P) is evaluated as:

given two paths P and Q, the link energy consumption profile of these two paths

Optionally assessed as: />

In addition to reversing the direction of edges in graph G (e.g., graph 1202 a) to obtain reverse graph G' (e.g., graph 1202 b), RCFP optionally also utilizes a reverse charging function

The reverse charge function optionally maps the battery SoC (β) before charging to the time required to obtain the resulting battery soc=m after charging. The reverse charge function is optionally obtained by adding the charge function cf: [0, M](associated with node 1204 in graph G (e.g., graph 1202 a)) into a reverse charging function +.>

(associated with the corresponding node 1204 in the reverse graph G' (e.g., graph 1202 b)). For example, the reverse charge function 1207a associated with node 1204B in fig. 12B is optionally the charge function 1206a associated with node 1204B in fig. 12A, but in the reverse direction. Similarly, the reverse charge function 1207B associated with node 1204e in fig. 12B is optionally the charge function 1206B associated with node 1204e in fig. 12A, but in the reverse direction. In some embodiments, the reverse charging function used in the RCFP is piecewise linear, concave, and/or monotonically decreasing. In some embodiments, the reverse charge function used in the RCFP has a range [ τ ] _max ，0]Wherein τ _max Is the time required for a given charging station associated with node v to charge the vehicle battery from 0 to msc. In addition, in some embodiments, the process includes, in some embodiments,

and->

In view of the above, the RCFP optionally includes one or more of the following steps. At a node v in the graph G 'corresponding to the path end point (e.g., a node 1204f in fig. 12C), a label l' =is optionally created <0，0，⊥，⊥>And adds it to a priority queue PQ (e.g., a queue or stack data structure, whichOptionally having additionally a "priority" associated with it in a priority queue, elements with high priority optionally being served before elements with low priority), optionally storing tags in ascending order of total travel time. This node is optionally associated with a reverse start SoC function 1210 as shown in fig. 12C (e.g., corresponding to SoC beta of the vehicle at the end of the journey from nodes 1204a to 1204 f) _t )。

When RCFP reaches a node v (e.g., nodes 1204c and 1204d in fig. 12B) other than a node (e.g., node 1204a in fig. 12B) corresponding to the path start point in the graph G 'that is not related to the charging function, the label l' =<τ _P ，0，⊥，f _P >Optionally create and add to L _uns (v) Which is optionally a tag set for pending tags. In some embodiments, L _uns Is implemented as a minimum heap with total feasible travel time as a key. P is optionally a sub-path from the current node to node T (e.g., node 1204f in FIG. 12B), and

when RCFP reaches a first node v (e.g., node 1204e in fig. 12D) associated with the charging function in the backward search other than the node corresponding to the path start point in the graph G '(e.g., node 1204a in fig. 12D), the label l' = <τ _P ，β _t +c _P ，v，f _P >Optionally create and add to L _uns (v) A. The invention relates to a method for producing a fibre-reinforced plastic composite As previously described, P is optionally a sub-path, τ, from the current node (e.g., node 1204e in fig. 12D) to node T (e.g., node 1204f in fig. 12D) _P Optionally the total travel time over P, and c _P Optionally the total energy consumption at P. In some implementations, at node v, a reverse start SoC function 1211 associated with node 1204e is determined based on reverse charge function 1207b and reverse start SoC function 1210 in fig. 12D (e.g., has propagated to node 1204e according to edge 1209e in terms of time and/or energy consumption). For example, the reverse start SoC function 1211 in fig. 12D reflects the charge function 12 in fig. 12C07b and reverse start SoC function 1210.

When RCFP reaches a subsequent node v associated with the charging function (e.g., node 1204b in fig. 12E) in the backward search, tag l' = < τ _t ，β′ _u ，u，f _[u...v] >Optionally from PQ. u optionally corresponds to the last charging station in the search (e.g., associated with node 1204E in fig. 12E). Reverse start SoC function b' _l′ (β) is optionally determined (e.g., based on the characteristics of the charge function 1207a and the reverse start SoC function 1211 in fig. 12D). In some embodiments of the present invention, in some embodiments,

In some embodiments, the reverse charging function used by the RCFP is piecewise linear; thus, optionally b' _l A tag is created for each breakpoint B of (e.g., a breakpoint based on the breakpoints in reverse charge function 1207a or 1207B). Specifically, for each breakpoint b= (τ _B ，SoC _B ) Label l' =<τ _P +b′(SoC _B )，SoC _B ，v，f _P >Optionally create and add to L _uns (v)。

When RCFP reaches node v in graph G ' corresponding to the start point of the path (e.g., node 1204a in fig. 12E), the search optionally terminates and backtracks to determine a path from node v in graph G ' corresponding to the end point of the path (e.g., node 1204f in fig. 12E) to node v in graph G ' corresponding to the start point of the path (e.g., node 1204a in fig. 12E). It should be noted that in some embodiments that perform RCFP, the tag-dominant condition is defined as tag l 'under the following conditions' ₁ Dominant tag l' ₂ : if and only if

(when beta is not less than 0).

To obtain an SCM between the starting node (e.g., node 1204 a) and the ending node (1204 f), rather than terminating when the RCFP reaches the starting node, the RCFP may continue to operate until the PQ is empty. Doing so will optionally provide a set of all pareto optimal viable paths from the start node to the end node, which optionally forms an SCM between the start node and the end node for a given remaining SoC at the end node.

An exemplary algorithm for determining the SCM between the source node s and the target node t is optionally as follows:

/>

in the above exemplary algorithm, L _set (v) Optionally a tag set for pending tags.

As previously mentioned, some embodiments of the present disclosure relate to systems and methods for generating a buffer map BM between a source node s and a target node t, the buffer map BM optionally being a function BM: [0, M ] such that the BM is evaluated for a given buffered SoC b ε [0, M ] to return the shortest path on which the SoC does not drop below b, optionally except at the charging station and/or source/destination nodes. The buffer map optionally has one or more of the same benefits as the starting charge map, including alternative routes for generating and/or displaying to drivers associated with different stranded risks (e.g., because they are associated with different buffer socs). It is noted that the buffer map is optionally different from the starting charge map, as the alternative routes in the buffer map are optionally different based on the predicted vehicle behavior along the route (e.g., rather than based on the starting SoC).

In some embodiments, the buffer map is determined using Iterative Charge Function Propagation (ICFP). Each iteration optionally starts with a choice of buffered SoC values b' e0, m. Then, a Charge Function Propagation (CFP) algorithm is run that returns the shortest possible path P ' such that the minimum SoC of the vehicle along P ' is equal to b '. The set of such paths P' optionally constitutes a set of paths from s to t in the buffer map. Thus, an exemplary algorithm of the present disclosure for determining a buffer map includes two parts: returning a first portion of the shortest possible path P' that involves the current buffered SoC value in the current iteration, and calculating an increased second portion of the buffered SoC value for each iteration.

In view of the above, an exemplary ICFP algorithm includes one or more of the following steps. In some embodiments, the first iteration of the exemplary algorithm starts with b' =0. The algorithm optionally proceeds from having vehicle beta _s Node s of the initial SoC of (a) starts and propagates towards t. For example, referring to fig. 12F, the exemplary algorithm begins at node 1204a in graph G1202 a and propagates toward node 1204F in fig. 12F. The nodes, edges, and/or charging functions shown in fig. 12F are optionally the same as those shown and described with reference to fig. 12A. At each node, the ICFP optionally is at L _uns (v) The tag 1 (e.g., similar to that described above with reference to RCFP), the tag 1 will be described in more detail later.

For example, in a scenario where the ICFP optionally follows a search (e.g., corresponding to nodes 1204b and 1204e in fig. 12F) through two charging stations u 'and u and reaches node v, cf' _u The break point of (2) is optionally

Wherein the method comprises the steps of

Is a tuple (τ' _i ，SoC′ _i ) And SoC' _i Is the charging time τ 'of the vehicle at the charging station u' _i The resulting SoC thereafter. For example cf' _u Optionally corresponding to the charging function 1206a associated with node 1204b in fig. 12F, and breakpoint +.>

Optionally corresponding to the breakpoint of the charge function 1206a in fig. 12F. Similarly, cf _u Is optionally +.>

Wherein->

Is a tuple (τ) _i ，SoC _i ) (e.g., breakpoint of charge function 1206b associated with node 1204e in fig. 12F), and SoC _i Is the charging time tau of the vehicle at the charging station u _i The resulting SoC thereafter. SoC after charging at a given charging station u is optionally called +.>

In addition, if cf' _u Is just below +.>

It is optionally called +.>

For example, referring to FIG. 12F, if +.>

(e.g., just) above level 1220b in charge function 1206a, then +.>

Optionally corresponding to a breakpoint at level 1220b in charge function 1206 a. Thus, the first and second substrates are bonded together,

similarly, for cf _u ，/>

When ICFP reaches a given node v (e.g., nodes 1204b to 1204e in fig. 12F), the labels for searching are optionally represented by l=<τ _t ，β _u ，u，f _[u...v] ，δ，λ>Given, the tag is optionally created and added to L _uns (v) Wherein:

τ _t total travel time from s to t

β _u Arriving SoC at the last charging station

u = last charging station node

f _[u...v] Energy consumption profile of =road u … v

δ＝cf _u At the position of

Charging rate at->

It should be noted that λ optionally represents a maximum buffered SoC to which the vehicle may be charged at charging station u without losing the charge rate (e.g., optionally, exceeding a threshold amount, such as 10%, 20%, 30%, 40%, etc.). For example, in connection with the charge function 1206a in fig. 12F, if the SoC of the vehicle is represented by the level 1220a when the node 1204b is reached, λ is optionally the difference between the levels 1220b and 1220 a. In some embodiments, delta and lambda are only

When (e.g. when the road segment [ u' … u ]]Is a critical road segment) is set in the label for the node. In some embodiments, the segments of path P are part of P between adjacent charging stop points, and the critical segments of path P are segments where the SoC drops to or below b. For example, referring to fig. 12F, the portion 1218 corresponding to the slave nodes 1204b to 1204e of the path is optionally a road segment of the slave nodes 1204a to 1204F of the path, and if the SoC of the vehicle is estimated to drop (or fall below) b during that road segment, the portion is optionally a critical road segment of the path.

In each iteration, the ICFP optionally collects a complete non-dominant tag set at the target node t. In some embodiments, tag l dominates l' in the following case: 1) The total travel time of l is less than the total travel time of l'; 2) Delta epsilon l>Delta 'e l'; 3) lambda εl<Lambda 'e l'. Thus, in some embodiments, tag l dominates l' if it represents a path that is less time consuming and has a faster charging station available to charge to a lower maximum buffered SoC. The set of labels collected at t is optionally l= { L ₁ ,l ₂ ,…,l _m }. Each of the collected tags optionally represents a viable path, wherein the SoC along the path does not drop below b.

After the labels are collected (e.g., once node T1204F is reached in the current iteration of the ICFP), the shortest feasible path P that can be found in the current iteration is optionally determined (e.g., corresponding to label l having the shortest total travel time in the label set _t ) To the maximum buffer charge of the vehicle battery at the charging station adjacent to the critical section of the road. This determination may be geometrically determined using an X-Y plot such as that shown in FIG. 12G. The X-Y plot of fig. 12G has an X-axis representing the total travel time of a given path associated with tag l and a Y-axis representing the buffered SoC of the given path associated with tag l. In some embodiments, it should be noted that the viable path may have multiple critical road segments, with charging stations adjacent thereto optionally allowing the vehicle to add buffer power at different rates, and allowing the vehicle to maintain the same charge rate for different limited buffer power. Thus, the restrictive critical section of the path (which is optionally the critical section of the path controlling the characteristics of the line plotted on the X-Y plot) is optionally the section with the fastest charge rate, and allows the vehicle to maintain the same charge rate in all critical sections along the path until the lowest buffered SoC.

Returning to fig. 12G, a label line segment is optionally added to the X-Y plot of each label l. For example, fig. 12G shows an example in which a set of tags includes three tags corresponding to different paths, one tag corresponding to each of tag line segment 1224a, tag line segment 1224b, and tag line segment 1224 c. The given tag line 1224 has a slope delta and X intercept, the slope optionally representing the charge rate of a restrictive critical road segment along the viable path, the intercept being equal to the total travel time τ of the given tag _t . For example, the label line segment 1224b in fig. 12G optionally has a slope corresponding to the slope 1222 of the portion of the charging function 1206a from 1220a to 1220b in fig. 12F. As another example, the tag line 1224a in fig. 12G optionally has a slope corresponding to the slope of the charging function 1206 b. Between tag line segments 1224a and 1224b in FIG. 12GThe slope difference optionally corresponds to 1225 (e.g., the slope difference of the relevant portions of the charging functions 1206a and 1206 b) shown in fig. 12F. In some embodiments, the maximum ordinate of the label line segment in the X-Y plot in FIG. 12G is given by λ.

Once the label line segment is drawn on the X-Y plot, a global minimum buffered SoC (lambda _min ) In tag L, the vehicle may charge up to the global minimum buffer SoC at the fastest. Lambda (lambda) _min Optionally by: starting with the label segment corresponding to the label in L, which corresponds to the shortest feasible path in the current iteration (e.g., L _t ) (e.g., the shortest total travel time at the minimum buffer SoC, e.g., zero), such as label line segment 1224a in fig. 12G, and the intersection of that label line segment with (e.g., all) other label line segments (e.g., label line segments 1224b and 1224c in fig. 12G) is identified on the X-Y plot. Lambda (lambda) _min Optionally given by the buffered SoC at the lowest intersection on the Y-axis in the X-Y plot. For example, referring to fig. 12G, λ _min Optionally the Y value of intersection 1226. Lambda (lambda) _min Optionally is a maximum buffered SoC that may be added to the vehicle in the current iteration of the ICFP (e.g., corresponding to an increase in SoC between levels 1220a and 1220b on charge function 1206a in fig. 12F).

Corresponding to l in the current iteration of ICFP _t A viable path (e.g., corresponding to tag line 1224 a) is optionally added to the buffer map (and a viable path corresponding to the buffered SoC value b' of the current iteration). The ICFP then optionally continues with the next iteration for which the buffered SoC value b' is optionally set from the current iteration to λ _min . For each iteration, the above steps are optionally performed, resulting in additional feasible paths being added to the buffer map for corresponding different buffered SoC values. Furthermore, as b' increases for each iteration, the ICFP optionally becomes more selective, and the number of possible paths from s to t optionally decreases. The iteration of the ICFP is optionally terminated when the value of b' is high enough that no viable paths are identified for that iteration. The set of possible paths that have been added to the buffer map optionally constitute a space between the start node s and the end node tBuffer mapping of paths.

Fig. 13 is a flow chart illustrating a method 1300 for efficiently identifying a viable route for a vehicle based on different initial states of charge for the vehicle and/or based on a minimum expected buffered state of charge for the vehicle during the route, according to some embodiments of the present disclosure. The method 1300 is optionally performed on a server and/or an electronic device (such as device 100, device 300, and device 500) as described above with reference to fig. 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.

As described below, the method 1300 provides a way to efficiently identify a viable route for a vehicle based on different initial states of charge of the vehicle and/or based on a minimum expected buffered state of charge of the vehicle during the route. The method enhances privacy and reduces the resources (e.g., processors, memory, etc.) required to generate the recommended route. For battery-operated electronic devices, increasing the operating efficiency of the device, i.e., saving power and extending the time between battery charges.

In some embodiments, method 1300 is performed at a server (e.g., such as server 1083 in fig. 10O) in response to receiving information about a start location and an end location of a trip from a separate device (e.g., a mobile phone, a tablet computer, a smart watch, etc., such as client device 1081 in fig. 10O). In some implementations, the starting and ending positions of the travel are provided in a navigation application installed on a separate device, such as described with reference to methods 700, 900, and/or 1100.

In some embodiments, the method includes determining (1302 a) a desired initial state of charge for a trip of the electric vehicle from a first location (e.g., a starting location of the trip provided in the navigation application) to a second location (e.g., a starting location of the trip provided in the navigation application). For example, given a first location and a second location, the method provides as output one or more suggested (e.g., shortest time and/or shortest distance) routes from the first location to the second location along with an associated initial state of charge required for the electric vehicle to successfully reach a destination in each of the one or more suggested routes. In some embodiments, the method takes as input the initial state of charge and outputs a shortest possible path between the first location and the second location. In some embodiments, a given proposed route includes information about streets, roads, turns, maneuvers, etc. to follow in addition to information about what charging locations along the route are charged and/or how long to charge at those charging locations. In some embodiments, the navigation application installed on the device in communication with the server also provides information to the server regarding battery and/or driveline characteristics of 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. In some embodiments, the desired initial state of charge utilization initiation charge map is determined as described with reference to fig. 12. In some embodiments, the following steps are performed not to determine a desired initial state of charge of a vehicle's journey between two locations, but to generate and/or display different viable paths between the two locations given (e.g., as input) different initial states of charge for the journey.

In some embodiments, the method includes identifying (1302 b) a first path (e.g., a set of roads connecting the first location and the second location in the physical world, maneuvers (e.g., turns, interworking facilities, etc.) from the first location to the second location, wherein the first path includes one or more intermediate locations between the first location and the second location (e.g., one or more locations between road segments of the first path, such as intersections, interworking facilities, highway exits, charging locations including charging stations, etc.), in some embodiments, the one or more intermediate locations are defined as locations between two road segments of the first path along the first path that have energy consumption characteristics that deviate by more than a threshold amount (e.g., energy consumed per unit length in the road segments has opposite signs and/or differs 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 of the plurality of nodes, the second location corresponds to a second node of the plurality of nodes, and the one or more intermediate locations correspond to one or more intermediate nodes of the plurality of nodes. For example, the nodes in the graph structure include nodes representing a first position, a second position, and an intermediate position, such as described with reference to fig. 12B. The edges connecting nodes in the graph structure optionally represent the various segments of the path previously described. Further, edges in the graphical structure are optionally associated with respective travel times (e.g., corresponding to the time spent using the electric vehicle to traverse the road segments of the first path corresponding to the edges) and/or respective energy consumption (e.g., corresponding to the energy consumed from and/or added to the battery of the electric vehicle by using the electric vehicle to traverse the road segments of the first path corresponding to the edges).

In some embodiments, the method includes providing (1302C) a starting reverse state of charge function (e.g., such as described with reference to RCFP and/or such as starting state of charge function 1210 in fig. 12C) corresponding to the first state of charge at the second node. For example, as input, the method is provided with a predetermined state of charge (e.g., 0%, 5%, 10%, 20%, 40%, etc.) at which the electric vehicle should end the trip or is operated according to the predetermined state of charge. The proposed route determined by the method optionally results in an estimated state of charge of the first state of charge at the second node. The initial reverse state of charge function optionally reflects the first state of charge (e.g., constant) as a function of mapping state of charge to time, wherein the non-reverse state of charge function will optionally reflect the first state of charge (e.g., constant) inversely as a function of mapping time to state of charge. In some embodiments, the starting reverse state of charge function is simply a state of charge scalar defining the ending state of charge of the vehicle at the end of the trip.

In some embodiments, the method includes propagating (1302D) the initial reverse 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 charge function (e.g., such as described with reference to RCFP and/or such as shown and described with reference to fig. 12C-12D). For example, the first intermediate node corresponds to a first intermediate position, wherein the charging station follows a first path from the first position to the second position. The first charging function optionally maps a starting state of charge of the battery at the first intermediate location and a time spent charging at the charging station to a resulting state of charge of the battery after charging the time, and optionally based on characteristics of the charging station and/or the electric vehicle battery (e.g., defining how quickly the electric vehicle battery is chargeable at the charging station over time).

In some embodiments, the method includes generating a first reverse state of charge function (e.g., such as described with reference to RCFP and/or such as shown and described with reference to fig. 12D or 12E) based on the reverse first charge function and the propagated starting reverse state of charge function. For example, reversing the first charging function optionally maps the state of charge of the electric vehicle battery prior to charging at the charging station at the first intermediate location to the time required to obtain a resulting state of charge (e.g., maximum state of charge) after charging. The first reverse state of charge function optionally considers a starting state of charge defined for the second node and maps the starting state of charge at the second node to the time spent charging at the charging station associated with the first charging function. One or more of the above and below steps are optionally performed when generating a starting charge map as described in the present disclosure. In some embodiments, a starting power map (e.g., additionally or alternatively, suggested/determined route) is transmitted from a server to a client device (e.g., device 1018) to facilitate route generation and/or display on the client device. The manner of determining charging and/or route recommendations along a path described above allows for an efficient generation of a suggested route between two locations given a desired initial state of charge, thereby providing dynamic and/or real-time interactions of a user with a navigation application.

In some embodiments, reversing the first charge function maps the state of charge of the electric vehicle prior to charging based on the first charge function to the time required for achieving the predetermined state of charge after the electric vehicle is charged based on the first charge function (e.g., such as reverse charge functions 1207a and 1207B in fig. 12B). In some embodiments, the charging function is associated with a charging station, and maps the arrival state of charge of the vehicle and the time spent charging at the charging station to the state of charge after the vehicle is charged. The reverse charging function optionally reverses the mapping of the corresponding charging function and maps the state of charge prior to charging the vehicle to the time required to charge at the charging station to obtain a resulting state of charge (e.g., 100%, 90%, 80%, etc. state of charge). The reverse charge function is optionally used by the RCFP as described with reference to fig. 12.

In some embodiments, determining the desired initial state of charge of the electric vehicle's journey from the first location to the second location further comprises (and/or determining the starting charge map (optionally not determining the desired initial state of charge of the electric vehicle's journey from the first location to the second location) further comprises) generating a second reverse state of charge function based on the reverse second charge function and the propagated first reverse state of charge function, wherein the reverse second charge function corresponds to a second charge 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). For example, the reverse state of charge function is determined at node 1204b in fig. 12E. The reverse state of charge function is optionally based on one or more of the reverse second charge function, the reverse first charge function, and/or the characteristics of the first reverse state of charge function (e.g., having propagated from the first intermediate node to the second intermediate node in terms of time and/or energy consumption).

In some embodiments, determining the desired initial state of charge of the electric vehicle for the journey from the first location to the second location further comprises (and/or determining the starting charge map (optionally not determining the desired initial state of charge of the electric vehicle for the journey from the first location to the second location) further comprises) determining a first recommended charge of the electric vehicle associated with the first charge function and a second recommended charge of the electric vehicle associated with the second charge function based on the first reverse state of charge function and the second reverse state of charge function. For example, based on a plurality of reverse state of charge functions generated by the RCFP at a plurality of nodes associated with charging stations, the RCFP optionally identifies how much to charge at each of the charging stations to achieve a shortest possible path from a starting node to an ending node. For example, estimating the charge rate at the state of charge at which the vehicle will reach each of the charging stations based on the RCFP determines that the vehicle should be charged for 15 minutes at the first charging station and 30 minutes at the second charging station (e.g., instead of 55 minutes at the first charging station or 60 minutes at the second charging station), thereby saving 10 minutes for the total journey.

In some embodiments, determining the desired initial state of charge of the electric vehicle for the trip from the first location to the second location further comprises (and/or determining the starting charge map (optionally not determining the desired initial state of charge of the electric vehicle for the trip from the first location to the second location) further comprises) determining the desired initial state of charge of the electric vehicle for the trip from the first location to the second location based on the determined first and second recommended amounts of charge. The viable paths added to the starting charge map (e.g., which are based on the determined first recommended charge amount and/or second recommended charge amount) optionally correspond to different initial states of charge. In determining at least a portion of the starting charge map associated with the first location and the second location using the RCFP, the starting charge map may be used to map an initial state of charge to a shortest possible path for the initial state of charge from the first location to the second location (e.g., because various paths in the starting charge map are associated with different initial states of charge).

In some embodiments, determining the desired initial state of charge of the electric vehicle for the journey from the first location to the second location further comprises (and/or determining the starting charge map (optionally not determining the desired initial state of charge of the electric vehicle for the journey from the first location to the second location) further comprises: identifying a second path different from 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 being represented by a respective plurality of nodes, the first location corresponding to a first respective node of the respective plurality of nodes, the second location corresponding to a second respective node of the respective plurality of nodes, and the one or more respective intermediate locations corresponding to one or more respective intermediate nodes of the respective plurality of nodes (e.g., if there are a plurality of different paths (e.g., passing through different intermediate nodes) from the first location to the second location, optionally performing RCFP for each of the plurality of different paths in the same manner as described with reference to the first path and/or with reference to fig. 12A-12E); providing a respective starting inverse state of charge function corresponding to the first respective state of charge at the second respective node; propagating a respective initial reverse state of charge function from the second respective node to a first respective intermediate node of the one or more respective intermediate nodes, wherein the first respective intermediate node is associated with a first respective charge function; a first respective reverse state of charge function is generated based on the reverse first respective charge function and the propagated respective starting reverse state of charge function, and a desired initial state of charge for a journey of the electric vehicle from the first location to the second location is determined based on the first reverse state of charge function and the first respective reverse state of charge function. For example, the same RCFP step as the first path is optionally performed on the second path. A shortest possible path for a given starting state of charge is optionally determined for each of these paths, and a shorter one of these shortest possible paths is optionally determined as the shortest possible path from the first location to the second location for the given starting state of charge. In some embodiments, the shorter path is added to the starting charge map associated with the first and second locations and corresponding initial states of charge, and the longer path of the shortest possible paths is not added. Thus, in some implementations, the starting charge maps associated with the first location and the second location include different paths (e.g., through different intermediate nodes) for different starting states of charge from the first location to the second location.

In some embodiments, the method includes determining a shortest path (e.g., a shortest possible path) between the first location and the second location, wherein the shortest path maintains a state of charge of the electric vehicle above a buffered state of charge (e.g., optionally except at locations associated with the charging station and/or the second location), including identifying a critical road segment in the first candidate path between the first location and the second location (e.g., the first candidate path is optionally a path used in a given iteration of the ICFP). In some embodiments, the segments of the path are part of the path between adjacent charging stations, and the critical segments are segments where the state of charge of the vehicle drops to or below the buffered state of charge value set in the current iteration of the ICFP. In some embodiments, the candidate path defines a charge (if any) at the charging station along the path, wherein: the candidate path includes one or more respective intermediate positions between a first position and a second position, the candidate path being represented by a respective plurality of nodes, the first position corresponding to a first respective node of the respective plurality of nodes, the second position corresponding to a second respective node of the respective plurality of nodes, and the one or more respective intermediate positions corresponding to one or more respective intermediate nodes of the respective plurality of nodes (e.g., such as described with reference to graph 1202a in fig. 12F), and the critical road segment is a road segment (e.g., critical road segment 1218 shown in fig. 12F) on the candidate path that connects adjacent intermediate nodes of the respective intermediate nodes associated with the respective charging function during which a state of charge of the electric vehicle is estimated to be less than or equal to a first respective buffered state of charge (e.g., a buffered state of charge value for a current iteration of the ICFP), wherein the adjacent intermediate nodes include the first respective intermediate node and the second respective intermediate node, and the first respective intermediate node is between the first respective node and the second respective intermediate node of the plurality of nodes (e.g., the first respective intermediate node is closer to the starting node than the first respective intermediate node). For example, the first corresponding intermediate node is node 1204b in fig. 12F, and the second corresponding intermediate node is node 1204e in fig. 12F. In some embodiments, the method includes representing the additional charge time at the first respective intermediate node as a function of mapping the total travel time of the candidate path to the respective buffer state of charge. For example, the additional charge time at the first respective intermediate node corresponds to an additional buffered state of charge quantity that may be added to the vehicle in the current iteration of the ICFP; for example, before the charge rate at the charging station corresponding to the first respective intermediate node decreases (e.g., exceeds a threshold amount, such as 10%, 20%, 30%, 40%, etc.), additional charge time may be added to the vehicle at that charging station. In some embodiments, the additional charge times and additional buffer states of charge that may be added at a given charging station are represented in a graph, such as shown in fig. 12G, where each charging station is represented by a line/function (e.g., 1224a-1224 c) in the graph. As described in connection with fig. 12G, the X-Y plot in fig. 12G maps total travel time to additional buffer states of charge. It should be appreciated that in some embodiments, determining the shortest path (e.g., the shortest possible path) between the first location and the second location, where the shortest path maintains the state of charge of the electric vehicle above the buffered state of charge (e.g., as part of determining the buffer map), is performed independently (e.g., without performing) of the previously described steps involving determining the starting charge map. In some embodiments, a set of buffer maps and starting power maps for a given starting location and ending location are determined. The above-described manner of identifying the shortest path between two locations allows for the suggested route between the two locations to be effectively generated given a desired minimum state of charge, thereby providing dynamic and/or real-time interactions of the user with the navigation application.

In some embodiments, 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 buffered state of charge. For example, ICFP iterations optionally start with a corresponding buffer state of charge of zero, which is optionally lower than the target buffer state of charge. The 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 paths for at least a desired buffer state of charge are identified. The set of such candidate paths optionally refers to a buffer map mapping a buffer state of charge from a source to a target destination to the shortest possible path that maintains the buffer state of charge.

In some embodiments, 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 a current iteration of the ICFP, determining that the vehicle reaches the first respective intermediate node at 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 a shortest path between the first location and the second location (e.g., as part of determining a buffer map for a trip between the first location and the second location) further comprises: an additional state of charge amount of the electric vehicle is identified that is higher than the respective state of charge that may be added at the first respective intermediate node associated with the first respective charge function without losing a charge rate that is greater than a threshold amount (e.g., 10%, 20%, 30%, etc.). For example, in the current iteration of the ICFP, it is determined how much additional charging can be performed at the front charging station of the critical road segment. In some embodiments, the further charge amount is limited to that portion of the charge function at a front charging station of the critical road segment during which the charge rate does not decrease by more than a threshold amount relative to the charge rate when the vehicle first begins charging at that charging station at its reached state of charge. The amount of charge also optionally corresponds to the intersection 1226 in fig. 12H.

In some implementations, the method includes identifying a second critical road segment in the first candidate path between the first location and the second location based on a second corresponding buffered state of charge (e.g., in a next iteration of the ICFP) that is equal to the corresponding state of charge of the electric vehicle increased by an additional state of charge amount. For example, for the next iteration of the ICFP, 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 state of charge amount determined for the current iteration, as described with reference to fig. 12H. The feasible path corresponding to the shortest total travel time of the current iteration of the ICFP is optionally added to the buffer map as corresponding to the buffer state of charge associated with the current iteration. The step of determining a buffer map described above is then optionally performed with updated buffer state of charge values for the next iteration.

As described above, one aspect of the present technology is to collect and use data available from specific and legal sources to improve the display of device location information provided to a user. The present disclosure contemplates that in some instances, the collected data may include personal information data that uniquely identifies or may be used to identify a particular person. Such personal information data may include demographic data, location-based data, online identifiers, telephone numbers, email addresses, home addresses, data or records relating to the user's health or fitness level (e.g., vital sign 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 may be used to benefit users. For example, personal information data may be used to display a current location of a user, to display a favorite or recently accessed location of a user, and/or to provide suggested navigation routes. Thus, using such personal information data enables a user to have information about the user's location or the device's location. In addition, the present disclosure contemplates other uses for personal information data that are beneficial to the user.

The present disclosure contemplates that entities responsible for collecting, analyzing, disclosing, transmitting, storing, or otherwise using such personal information data will adhere to established privacy policies and/or privacy practices. In particular, it would be desirable for such entity implementations and consistent applications to generally be recognized as meeting or exceeding privacy practices required by industries or governments maintaining user privacy. Such information about the use of personal data should be highlighted and conveniently accessible to the user and should be updated as the collection and/or use of the data changes. The user's personal information should be collected only for legitimate use. In addition, such collection/sharing should only occur after receiving user consent or other legal basis specified in the applicable law. Moreover, such entities should consider taking any necessary steps to defend and secure access to such personal information data and to ensure that others having access to the personal information data adhere to their privacy policies and procedures. In addition, such entities may subject themselves to third party evaluations to prove compliance with widely accepted privacy policies and practices. In addition, policies and practices should be tailored to the particular type of personal information data being collected and/or accessed and adapted to applicable laws and standards, including jurisdictional-specific considerations that may be used to impose higher standards. For example, in the united states, the collection or acquisition of certain health data may be governed by federal and/or state law, such as the health insurance flow and liability act (HIPAA); while health data in other countries may be subject to other regulations and policies and should be processed accordingly.

In spite of the foregoing, the present disclosure also contemplates embodiments in which a user selectively prevents use or access to personal information data. That is, the present disclosure contemplates that hardware elements and/or software elements may be provided to prevent or block access to such personal information data. For example, the present technology may be configured to allow a user to choose to participate in the collection of personal information data "opt-in" or "opt-out" during or at any time after the registration service. In another example, the user may choose not to enable the customized navigation route. In yet another example, the user may choose to limit the location information of the shared device or to block the display of custom routes or license plate information altogether. In addition to providing the "opt-in" and "opt-out" options, the present disclosure also contemplates providing notifications related to accessing or using personal information. For example, the user may be notified when the map application is displayed that the characteristics of his vehicle (e.g., license plate number) will be used, and then be reminded again before the customized route is determined and/or displayed.

Further, it is an object of the present disclosure that personal information data should be managed and processed to minimize the risk of inadvertent or unauthorized access or use. Once the data is no longer needed, risk can be minimized by limiting the data collection and deleting the data. In addition, and when applicable, included in certain health-related applications, the data de-identification may be used to protect the privacy of the user. De-identification may be facilitated by removing identifiers, controlling the amount or specificity of stored data (e.g., collecting location data at a city level instead of at an address level), controlling how data is stored (e.g., aggregating data among users), and/or other methods such as differentiated privacy, as appropriate.

Thus, while the present disclosure broadly covers the use of personal information data to implement one or more of the various disclosed embodiments, the present disclosure also contemplates that the various embodiments may be implemented without accessing such personal information data. That is, various embodiments of the present technology do not fail to function properly due to the lack of all or a portion of such personal information data. For example, location information may be generated and delivered to the user based on non-specific information data or a substantially minimum amount of identifying information, such as based on a determination of a proposed route similar to an average driving range of a vehicle of the user's vehicle.

It is well known that the use of personally identifiable information should follow privacy policies and practices that are recognized as meeting or exceeding industry or government requirements for maintaining user privacy. In particular, personally identifiable information data should be managed and processed to minimize the risk of inadvertent or unauthorized access or use, and the nature of authorized use should be explicitly stated to the user, such as by anonymously processing the vehicle license plate as described above in connection with method 1100.

The foregoing description, for purposes of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application to thereby enable others skilled in the art to best utilize the invention and various described embodiments with various modifications as are suited to the particular use contemplated.

Claims (19)

1. A method, comprising:

at an electronic device in communication with a display generation component and one or more input devices:

displaying a map user interface via the display generating component;

while displaying the map user interface, receiving, via the one or more input devices, a first user input corresponding to a request to display directions from a first location to a second location via a given mode of transportation; and

in response to receiving the first user input:

in accordance with a determination that a first vehicle is a currently selected vehicle to which directions are displayed in the map user interface, displaying a first proposed route from the first location to the second location in the map user interface based on a first characteristic of the first vehicle; and

in accordance with a determination that a second vehicle different from the first vehicle is the currently selected vehicle to which directions are displayed in the map user interface, displaying a second proposed route different from the first proposed route from the first location to the second location in the map user interface based on a second characteristic of the second vehicle;

while displaying the first proposed route from the first location to the second location, receiving, via the one or more input devices, a second user input corresponding to a request to display one or more representations of one or more road segments associated with the first proposed route; and

In response to receiving the second user input, concurrently displaying, via the display generating component, the one or more representations of one or more road segments associated with the first proposed route including one or more directions to the first proposed route and one or more charging or refueling stopping points in the first proposed route.

2. The method according to claim 1, wherein:

the first characteristic of the first vehicle includes a first current estimated range of the first vehicle;

the first proposed route is based on the first current estimated range;

the second characteristic of the second vehicle includes a second current estimated range of the second vehicle different from the first current estimated range; and is also provided with

The second proposed route is based on the second current estimated range.

3. The method according to claim 2, wherein:

in accordance with a determination that the first current estimated range is less than a range of the first proposed route from the first location to the second location, the first proposed route includes a proposed stopping point for increasing a remaining range of the first vehicle.

4. A method according to claim 3, wherein:

in accordance with a determination that the first vehicle is associated with a first charging network, the proposed parking spot for increasing the remaining range of the first vehicle is a first parking spot associated with the first charging network.

5. The method according to claim 1, wherein:

the first characteristic of the first vehicle includes a first current estimated range of the first vehicle; and is also provided with

The first proposed route is based on the first current estimated range, the method further comprising:

in response to the first user input:

in accordance with a determination that the third vehicle is the currently selected vehicle to which directions are displayed in the map user interface, a third proposed route is displayed in the map user interface from the first location to the second location that is not based on the currently estimated range of the vehicle.

6. The method according to claim 1, wherein:

displaying the first proposed route from the first location to the second location includes displaying an estimated total travel time of the first proposed route; and is also provided with

In accordance with a determination that the first proposed route includes a proposed stopping point for increasing a remaining range of the first vehicle, the estimated total travel time includes increasing an estimated time of the remaining range of the first vehicle at the proposed stopping point.

7. The method of claim 1, further comprising:

one or more representations of one or more road segments associated with the first proposed route are displayed via the display generating component, wherein respective representations of respective road segments include an indication of an estimated state of the first characteristic of the first vehicle during the respective road segments.

8. The method of claim 1, further comprising:

receiving, via the one or more input devices, user input corresponding to a request to select the second vehicle as the currently selected vehicle when the first vehicle is the currently selected vehicle and when the first proposed route from the first location to the second location is displayed; and

in response to receiving the user input corresponding to the request to select the second vehicle as the currently selected vehicle, the second proposed route is displayed in the map user interface.

9. The method of claim 1, further comprising:

determining that the device has reached a proposed stopping point for increasing a remaining range of the first vehicle while navigating along the first proposed route; and

In response to determining that the device has reached the proposed parking spot for increasing the remaining range of the first vehicle:

in accordance with a determination that a first type of accessory is required to increase the remaining range of the first vehicle, an indication of the first type of accessory is displayed via the display generating component.

10. The method of claim 1, further comprising:

determining that the device has reached a proposed stopping point for increasing a remaining range of the first vehicle while navigating along the first proposed route;

in response to determining that the device has reached the proposed parking spot for increasing the effective range of the first vehicle, displaying, via the display generating component, a first affordance for suspending the navigation along the first proposed route;

while displaying the first affordance for suspending the navigation, receiving user input selecting the first affordance via the one or more input devices; and

in response to receiving the user input selecting the first affordance, displaying via the display generation component:

a second affordance for resuming navigation along the first proposed route; and

An indication of the first characteristic of the first vehicle while the first characteristic is increasing.

11. The method of claim 1, further comprising:

determining that a current estimated range of the first vehicle is less than a remaining range of the first proposed route from a current location to the second location while navigating along the first proposed route; and

in response to determining that the current estimated range of the first vehicle is less than the remaining travel distance of the first proposed route from the current location to the second location, the first proposed route is updated to include a proposed stopping point for increasing the remaining range of the first vehicle.

12. The method according to claim 1, wherein:

the first characteristic of the first vehicle is associated with a first travel limit of the first vehicle;

the first proposed route is based on the first travel limit;

the second characteristic of the second vehicle is associated with a second travel limit of the second vehicle that is different from the first travel limit; and is also provided with

The second proposed route is based on the second travel limit.

13. The method according to claim 12, wherein:

The first travel limit is determined using an anonymous characteristic corresponding to the first characteristic of the first vehicle.

14. The method according to claim 1, wherein:

the first characteristic of the first vehicle is associated with a first travel limit of the first vehicle; and is also provided with

The first proposed route is based on the first travel limit, the method further comprising:

in response to the first user input:

in accordance with a determination that a vehicle to which guidance is not currently selected in the map user interface is displayed, a third proposed route that is not based on travel restrictions from the first location to the second location is displayed in the map user interface.

15. The method according to claim 14, wherein:

according to the determination that the third recommended route passes through the area limited by the corresponding travel restriction, an indication that the third recommended route passes through the area limited by the travel restriction is displayed via the display generating means.

16. The method of claim 1, further comprising:

in accordance with a determination that a given route from the first location to the second location is associated with a travel limit:

in accordance with a determination that one or more criteria are met, displaying, via the display generating component, an affordance for adding information about a respective vehicle to the map user interface;

Receiving user input selecting the affordance via the one or more input devices; and

in response to receiving the user input, a process is initiated to add the information about the respective vehicle to the map user interface.

17. The method of claim 1, further comprising:

determining that a current location of the device meets one or more criteria associated with a travel limit of the first proposed route while navigating along the first proposed route; and

in response to determining that the current location meets the one or more criteria associated with the travel limit, an indication of the travel limit is displayed via the display generation component.

18. An electronic device, comprising:

one or more processors;

a memory; and

one or more programs, wherein the one or more programs are stored in the memory and configured to be executed by the one or more processors, the one or more programs comprising instructions for performing any of the methods of claims 1-17.

19. A non-transitory computer readable storage medium storing one or more programs, the one or more programs comprising instructions, which when executed by one or more processors of an electronic device, cause the electronic device to perform any of the methods of claims 1-17.

Images