Systems and methods for high accuracy location determination and energy dispensing - Patents.com

Abstract

Various systems and methods disclosed herein provide secure, cost-effective, and highly accurate location detection. In some implementations of systems and methods for highly accurate location detection, a mobile location device acquires and calculates location data from multiple sources without requiring expensive, power-inefficient processors. In some implementations, such secure, cost-effective, and highly accurate location detection by a mobile location device is used in improved vehicle-based transactions, such as energy dispensing and payment management systems and methods. In some such implementations, the mobile location device communicates with a remote geo-mapping server and a payment system to provide automated vehicle-based transactions, such as energy dispensing sessions and payments.

Description

[Technical field]

[0001] The present disclosure relates more generally to the fields of high precision location determination, cashless energy dispensing, wireless payment for energy dispensing, remote management and control for energy dispensing, and intelligent transportation systems. Summary of the Invention

[0002] Various systems and methods disclosed herein provide secure, cost-effective, efficient, and highly accurate location detection. In some implementations of the systems and methods for high-precision location detection, a mobile location device acquires and calculates precise location data from multiple sources, such as Global Navigation Satellite Systems (GNSS), Microelectromechanical Systems (MEMS), and Geographic Information Systems (GIS), without requiring expensive and power-inefficient processors to read raw GNSS data.

[0003] In some implementations, such secure, cost-effective, and highly accurate location detection by the mobile location device can be applied for use in improved energy dispensing, parking, tolling, and payment management systems and methods. In some such implementations, the mobile location device further communicates with a remote geomapping server and payment system to provide automated vehicle-based transactions such as energy dispensing, parking, tolling, and payment.

[0004] In some aspects, the techniques described herein relate to a location device that includes a processor and a memory device storing a plurality of instructions that, when executed by the processor, are configured to cause the processor to receive Global Navigation Satellite System (GNSS) data and vehicle motion data, the GNSS data and the vehicle motion data being associated with a vehicle, calculate a location of the vehicle based on the GNSS data and the vehicle motion data in an estimation filter operating in a first mode, determine that a speed of the vehicle is below a threshold speed, modify the estimation filter to operate in a second mode based on the speed being below the threshold speed, calculate a position location of the vehicle in the estimation filter operating in the second mode, at least some of the GNSS data and the vehicle motion data are modified so that the estimation filter determines a position location of the vehicle, and transmit the position location of the vehicle to a geo-mapping server to enable vehicle-based transactions.

[0005] In some aspects, the techniques described herein relate to a location device where changes in at least some of the GNSS data and vehicle motion data result in changes in vehicle speed data.

[0006] In some aspects, the techniques described herein relate to a location device where a change in at least some of the GNSS data and the vehicle motion data results in a change in the data of the vehicle yaw rate.

[0007] In some aspects, the techniques described herein relate to a location device, where the processor is further configured to calculate and capture a plurality of location points when the estimation filter is operating in the second mode.

[0008] In some aspects, the techniques described herein relate to a location device, where the speed of the vehicle is a first speed value received in the GNSS data, and the processor is further configured to receive one or more signal strength indicators in the GNSS data, determine from the one or more signal strength indicators not to use the first speed value, and calculate a second speed value based at least in part on the vehicle motion data.

[0009] In some aspects, the techniques described herein relate to a location device where the second velocity value is calculated at least in part using vehicle acceleration data from the vehicle motion data.

[0010] In some aspects, the technology described herein relates to a location device where the estimation filter is a Kalman filter, and where the Kalman filter includes multiple modes.

[0011] In some aspects, the technology described herein relates to a location device where a vehicle-based transaction is triggered based on the position location being at a predetermined location, the vehicle-based transaction being an energy dispensing session at the energy dispensing device.

[0012] In some aspects, the techniques described herein relate to a location device, where the processor is further configured to enable an energy dispensing session at the energy dispensing device using two-factor authentication, where a first authentication factor is based at least in part on a transmitted position location and a second authentication factor is based at least in part on a communication from a user device.

[0013] In some aspects, the technology described herein relates to a location device where communication from a user device identifies the energy dispensing device.

[0014] In some aspects, the technology described herein relates to a location device where the energy dispensing device is a first energy dispensing device and communication from a user device identifies a second energy dispensing device.

[0015] In some aspects, the technology described herein relates to a location device, where the energy dispensing device is a fuel pump.

[0016] In some aspects, the technology described herein relates to a location device where the energy dispensing device is an electric vehicle charger.

[0017] In some aspects, the technology described herein relates to a location device where a vehicle-based transaction is triggered based on the position location being at a predetermined location, the vehicle-based transaction being a parking session.

[0018] In some aspects, the technology described herein relates to a location device, where the predetermined location is a legal parking zone.

[0019] In some aspects, the techniques described herein relate to a location device where the instructions further cause a processor to determine that the vehicle is moving faster than a predetermined speed, send a message to a geo-mapping server indicating that the vehicle is moving faster than the predetermined speed, and terminate the parking session based on the sent message.

[0020] In some aspects, the technology described herein relates to a location device where the vehicle-based transaction is a toll collection transaction that automates toll payment based on the position location of the vehicle.

[0021] In some aspects, the techniques described herein relate to a method for processing a vehicle location that includes receiving Global Navigation Satellite System (GNSS) data and vehicle motion data, where the GNSS data and the vehicle motion data are associated with a vehicle; calculating, at an estimation filter operating in a first mode, a location of the vehicle based on the GNSS data and the vehicle motion data; determining that a speed of the vehicle is below a threshold speed; modifying the estimation filter to operate in a second mode based on the speed being below the threshold speed; calculating, at an estimation filter operating in the second mode, a position location of the vehicle, where at least some of the GNSS data and the vehicle motion data are modified so that the estimation filter determines a position location of the vehicle; and transmitting the position location of the vehicle to a geo-mapping server that enables vehicle-based transactions.

[0022] In some aspects, the techniques described herein relate to methods in which changes in at least some of the GNSS data and the vehicle motion data result in changes in vehicle speed data.

[0023] In some aspects, the techniques described herein relate to methods in which altering at least some of the GNSS data and the vehicle motion data results in alteration of the vehicle yaw rate data.

[0024] In some aspects, the techniques described herein relate to a method that further includes calculating and capturing a plurality of location points when the estimation filter is operating in the second mode.

[0025] In some aspects, the techniques described herein relate to a method, where a speed of the vehicle is a first speed value received in the GNSS data, the method further including receiving one or more signal strength indicators in the GNSS data, determining from the one or more signal strength indicators not to use the first speed value, and calculating a second speed value based at least in part on the vehicle motion data.

[0026] In some aspects, the techniques described herein relate to methods in which the second velocity value is calculated at least in part using vehicle acceleration data from the vehicle motion data.

[0027] In some aspects, the technology described herein relates to a method, wherein the estimation filter is a Kalman filter, and wherein the Kalman filter includes multiple modes.

[0028] In some aspects, the technology described herein relates to methods where a vehicle-based transaction is triggered based on the position location being at a predetermined location, and the vehicle-based transaction is an energy dispensing session at an energy dispensing device.

[0029] In some aspects, the techniques described herein relate to a method that further includes enabling an energy dispensing session at an energy dispensing device using two-factor authentication, where a first authentication factor is based at least in part on a transmitted position location and a second authentication factor is based at least in part on a communication from a user device.

[0030] In some aspects, the technology described herein relates to methods in which communication from a user device identifies an energy dispensing device.

[0031] In some aspects, the technology described herein relates to methods in which the energy dispensing device is a first energy dispensing device and communication from a user device identifies a second energy dispensing device.

[0032] In some aspects, the technology described herein relates to a method, wherein the energy dispensing device is a fuel pump.

[0033] In some aspects, the technology described herein relates to methods wherein the energy dispensing device is an electric vehicle charger.

[0034] In some aspects, the technology described herein relates to a method where a vehicle-based transaction is triggered based on the position location being at a predetermined location, and the vehicle-based transaction is a parking session.

[0035] In some aspects, the technology described herein relates to a method, wherein the predetermined location is a legal parking zone.

[0036] In some aspects, the techniques described herein relate to a method, further including determining that the vehicle is moving faster than a predetermined speed, sending a message to a geo-mapping server indicating that the vehicle is moving faster than the predetermined speed, and terminating the parking session based on the sent message.

[0037] In some aspects, the technology described herein relates to a method, wherein the vehicle-based transaction is a toll collection transaction that automates toll payment based on the position location of the vehicle. [Brief description of the drawings]

[0038] [Figure 1] 1 is a perspective view of several implementations of a vehicle having a mobile location device that communicates with a number of different systems to determine the vehicle's location with high accuracy. [Figure 2A] FIG. 1 is a block schematic diagram of the disclosed system and the communication patterns between its different elements, including devices (possibly through a mobile application or other communication means, including a vehicle display screen), a server (or multiple servers), a database (or multiple databases), and users, in some implementations. [Figure 2B] 1 is a block diagram illustrating several implementations of the various systems and methods, further illustrating multiple mobile location devices and multiple user devices. [Diagram 3] 1 is a block diagram illustrating several implementations of elements included in a mobile location device. [Figure 4] A block diagram illustrating several implementations of signaling between components of a mobile location device. [Diagram 5] 1 is a block diagram illustrating several implementations of connections between power subsystems of a mobile location device. [Figure 6] 1 is a block diagram illustrating several implementations of connections between human interface device subsystems of a mobile location device. [Figure 7] 4 is a flow chart illustrating several implementations of signal processing paths for location data in a mobile location device. [Figure 8] 1 is a flowchart illustrating several implementations of systems and methods for capturing and calculating coordinate data for a mobile location device. [Figure 9] 1 is a flowchart depicting several implementations of a mobile location device connecting with a geo-mapping server for secure communications. [Figure 10A] FIG. 13 is a diagram of an exemplary implementation for automating energy dispensing sessions based on vehicle location data. [Figure 10B] FIG. 13 is a diagram of an exemplary implementation for automating energy dispensing sessions based on vehicle location data. [Figure 10C] FIG. 13 is a diagram of an exemplary implementation for automating energy dispensing sessions based on vehicle location data. [Figure 10D] FIG. 13 is a diagram of an exemplary implementation for automating energy dispensing sessions based on vehicle location data. [Figure 10E] FIG. 13 is a diagram of an exemplary implementation for automating energy dispensing sessions based on vehicle location data. [Figure 10F] FIG. 13 is a diagram of an exemplary implementation for automating energy dispensing sessions based on vehicle location data. [Figure 11] 1A-1C illustrate several implementations of time domain transaction diagrams illustrating operational processes and communications between certain elements of the disclosed system. [Figure 12] 1 is a flowchart illustrating several implementations of systems and methods for automatically detecting and processing energy dispensing sessions. [Figure 13A] FIG. 1 illustrates an example implementation of initiating a parking session for a vehicle within a legal parking zone. [Figure 13B] FIG. 1 illustrates an example implementation of initiating a parking session for a vehicle within a legal parking zone. [Figure 13C] FIG. 1 illustrates an example implementation of initiating a parking session for a vehicle within a legal parking zone. [Figure 13D] FIG. 1 illustrates an example implementation of initiating a parking session for a vehicle within a legal parking zone. [Figure 13E] FIG. 1 illustrates an example implementation of stopping a parking session when a vehicle leaves a parking zone. [Figure 13F] FIG. 1 illustrates an example implementation of stopping a parking session when a vehicle leaves a parking zone. [Figure 14] 1A-1C illustrate several implementations of time domain transaction diagrams illustrating operational processes and communications between certain elements of the disclosed system. [Figure 15]1 is a flowchart illustrating some implementations of systems and methods for automatically detecting and processing parking sessions. [Figure 16A] FIG. 1 illustrates an example implementation of screenshots of a mobile application corresponding to the system state (currently active session). [Figure 16B] FIG. 1 illustrates an example implementation of a screenshot of a mobile application corresponding to a system state (no active sessions). [Figure 16C] FIG. 13 shows an example implementation of a screenshot of a mobile application corresponding to the state of the system (vehicle locating). [Figure 17A] 1 is a block schematic diagram illustrating an exemplary implementation in which components of a mobile location device are integrated or connected to a vehicle's on-board electronics system. [Figure 17B] 1 is a block schematic diagram illustrating an exemplary implementation in which components of a mobile location device are integrated or connected to a vehicle's on-board electronics system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0039] The disclosure herein provides various implementations of a secure, cost-effective, efficient, and highly accurate location detection system, from which one of ordinary skill in the art will appreciate various novel approaches and features developed by the inventors, which may be used individually or in combination with one another as desired, as seen herein.

[0040] In particular, references to described implementations, and to "one implementation," "implementation," "exemplary implementation," and the like herein indicate that the described implementation may include a particular feature, structure, or characteristic, but that not all implementations may include that particular feature, structure, or characteristic. Also, such phrases do not necessarily refer to the same implementation. Moreover, when a particular feature, structure, or characteristic is described in connection with one implementation, one of ordinary skill in the art may implement such feature, structure, or characteristic in association with other implementations, whether or not explicitly described.

[0041] FIG. 1 is a perspective view of some implementations of a location system 5 that provides low-cost, highly accurate location detection. The location system 5 includes a mobile location device 10. In some implementations, the mobile location device 10 can include one or more location processors capable of determining the location of the mobile location device 10 to within a few meters within a geographic area. In some implementations, the location accuracy is within an accuracy of 4 meters or less. However, other suitable levels of accuracy may be achieved. The mobile location device 10 can determine the location using one or more sources of location data. In some implementations, the mobile location device 10 can include a user interface, such as at least one indicator light 12 and multiple user interface buttons 18a-18b. The mobile location device 10 includes antennas 14 and 16, and in some implementations, the antennas are not visible and are housed within the mobile location device 10. It should be understood that the mobile location device 10 may include more or no indicator lights, fewer or more or no user interface buttons, and fewer or more or no antennas. The mobile location device 10 may, in some implementations, include a user interface screen (not shown). The mobile location device 10 may include other features discussed below. The mobile location device 10 may be located within a vehicle 20. The mobile location device 10 is configured to operate in a variety of different locations, including an "urban canyon" created when the mobile location device 10 and vehicle 20 travel through a city and are surrounded by buildings, such as buildings 22a and 22b.These "urban canyons" create multipath signal distortions that previously made it difficult for Global Navigation Satellite System (GNSS) receiver / processors (GNSS units) to resolve location without very expensive hardware solutions that require excessive amounts of power.

[0042] The mobile location device 10 communicates with a number of different devices and systems to help detect the location (i.e., geographic position) of the mobile location device 10, as shown in FIG. 1. In some implementations, the mobile location device 10 communicates with a number of different satellite systems, such as satellite system 50a, satellite system 50b, and satellite system 50c. The mobile location device 10 may receive location signals 52 from satellite system 50a, location signals 54 from satellite system 50b, and location signals 56 from satellite system 50c through antenna 16. Satellite system 50a may comprise a Global Positioning System (GPS) satellite system, which comprises multiple satellites. Satellite system 50b may comprise a Global Navigation Satellite System (GLONASS), which comprises multiple satellites. Satellite system 50c may comprise a Galileo satellite system, which comprises multiple satellites. It should be understood that in some implementations, the mobile location device 10 may receive signals from fewer satellite systems (e.g., satellite system 50a, but not the other satellite systems 50b and 50c). In another implementation, the mobile location device 10 may receive signals from more satellite systems than shown. In some implementations, when the mobile location device 10 cannot receive satellite signals, the mobile location device 10 may not receive signals from any satellites. In some implementations, the mobile location device 10 is a self-contained unit that includes one or more of the modules discussed in FIG. 3 (e.g., geolocation locating system 320, MEMS system 330, etc.). In some implementations, the mobile location device 10 as a self-contained unit can be removably installed in a vehicle, similar to a toll booth transponder. In some implementations, the mobile location device 10 may have access to one or more sensors in the vehicle.In some implementations in which the mobile location device 10 has access to one or more sensors within the vehicle (e.g., through the vehicle's CAN bus), the mobile location device 10 may not include one or more of the modules discussed in Figure 3 as these are already provided by the vehicle. Although the mobile location device 10 is described above as comprising multiple distinct components and as a system separate from the vehicle, the mobile location device 10 is an embedded system within the vehicle and can obtain data from one or more of the vehicle sensors. As an embedded system, one or more of the functions of the vehicle motion device 10, including the functions of the processor 310, can be integrated into an existing vehicle system.

[0043] The mobile location device 10 may communicate with the mobile network 110 through one or more cellular access points 100 via communication link 95 and through antenna 14. The cellular access points 100 may communicate with the mobile network 110 via communication link 105. It should be understood that the mobile network 110 may include hundreds or thousands of cellular access points 100 and communication links 105 to provide access to the mobile network 110. In some implementations, through the mobile network 110, the mobile location device 10 may communicate with one or more servers and databases in the data center 120 via communication link 117. In some implementations, through the mobile network 110, the mobile location device 10 may communicate with one or more servers and databases in the data center 120 via communication link 115. Such servers may be described herein as geo-mapping servers. In some implementations, the system 5 may include multiple different data centers spread across a particular country or the world to ensure that the mobile location device 10 has access to smooth, low latency communication to location services provided by the servers in the data center 120. In some implementations, the mobile network 110 provides a secure connection between the mobile location device 10 and the servers in the data center 120. In some implementations, the secure connection may be a virtual private network (VPN). However, other suitable secure connections may be used for the mobile location device 10 to communicate with the servers in the data center 120. In some implementations, the communication between the mobile location device 10 and the data center 120 is not secure. It should be understood that in some implementations, the mobile location device 10 may also have access to other servers or endpoints in communication with the mobile network 110. In some implementations, the system 5 may include multiple different mobile networks 110. In some implementations, the multiple different mobile networks may be located in different countries.In another implementation, some of the multiple different mobile networks are located in the same country. In some implementations, the mobile network 110 is a mobile virtual network (MVN). The mobile network 110 may be created as a virtual network that communicates through one or more other mobile networks. For example, the mobile network 110 may be formed using a connection through a first GSM-based mobile network and a second different GSM-based mobile network. When the mobile location device 10 moves between the first GSM-based mobile network and the second different GSM-based mobile network, the transition and data transmitted through the two different GSM-based mobile networks are seamlessly routed to the same location, creating a virtual mobile network.

[0044] The mobile location device 10 may communicate with the Internet 130 through the mobile network 110. The mobile network 110 may have one or more links to the Internet 130, such as link 117, that enable the mobile location device 10 to communicate with endpoints on the Internet 130. In some implementations, the mobile location device 10 may access services from endpoints (not shown) on the Internet 130. For example, the mobile location device 10 may access GPS correction data from a server accessible through the Internet 130. The mobile location device 10 may access other suitable services through the Internet 130. In some implementations, a server in the data center 120 may also communicate with endpoints through the Internet 130 via communication link 125.

[0045] The location system 5 also illustrates a user device 140. The user device 140 may be a mobile phone, a smartphone, or other suitable computer system, such as, for example, a laptop computer, a tablet device, or a smartwatch. In some implementations, the user device 140 may be a vehicle infotainment system included in the vehicle 20. In some implementations, the user device 140 of the system 5 may be a combination of two or more devices, for example, the user device 140 may include a smartphone and an infotainment system, or as another example, the user device 140 may include a smartphone, an infotainment system, and a smartwatch (not shown). In some implementations, the functionality of the mobile location device 10 and the user device 140 may be integrated into one device. The user device 140 is associated with the mobile location device 10. A server in the data center 120 stores the association between the user device 140 and the mobile location device 10. The user device 140 may communicate with one or more servers in the data center 120 to access a particular service. In some implementations, the user device 140 may be configured with a mobile location device 10 and applications to access information regarding various services such as refueling, recharging, parking, toll collection, curbside pickup, etc. The user device 140 may communicate with the mobile network 160 through one or more cellular access points 150 via communication link 145. The cellular access points 150 may communicate with the mobile network 160 via one or more communication links 155. It should be understood that the mobile network 160 may include hundreds or thousands of cellular access points 150 and communication links 145 to provide access to the mobile network 160. Through the mobile network 160, the user device 140 may communicate with one or more servers in the data center 120 via communication link 165.As mentioned above, multiple different data centers 120 may be used to provide services to user device 140. In some implementations, mobile network 160 and mobile network 110 may be the same mobile network, depending on the geographic locations of mobile location device 10 and user device 140 and the service configuration between networks 110 and 160 and devices 10 and 140.

[0046] Although not shown, the mobile location device 10 may also communicate directly with the user device 140. In some implementations, communication may occur over a short-range wireless link, such as Bluetooth, or over a hardwired link, such as Universal Serial Bus (USB) or Ethernet.

[0047] In various implementations, the communication links described herein may include hardwired or wireless communication links. It should be understood that not all communication links and network nodes used to form the illustrated communication links are shown in FIG. 1 or other figures.

[0048] It should be understood that the manner of communication of system 5 is not limited to the various systems and networks illustrated in Figure 1. Mobile location device 10 may communicate with any other suitable number of networks and over any other suitable communications links.

[0049] FIG. 2A is a block schematic diagram illustrating some implementations of a high-precision location system for vehicle-based transaction services such as parking and / or automated energy dispensing and payment, and possible links between its elements. A user 245, e.g., an individual driver or a company managing a fleet of company vehicles, uses a vehicle 20 (or multiple vehicles) that may be owned, rented, or used for employment and business operations. A mobile location device 10 may be located or included in the vehicle 20. A database 210 may store geographic objects or zones including geographic coordinates of locations such as legal parking zones, zones adjacent to fuel pumps, charging stations, toll booths, curbside pickup locations, and the like. In some implementations, the database 210 may be located in the data center 120 or one or more data centers. In some implementations, the database 120 may be stored on an external memory device of the mobile location device 10, such as a memory card (e.g., SD, micro SD, Compact Flash, etc.), USB flash drive, etc., or directly in the internal memory of a processing device, such as a flash memory in the mobile location device 10. In some implementations, the database includes geographic information (e.g., one or more geographic coordinates) that define zones for geolocated polygons, which may also be referred to as geolocated zones. In some implementations, such geographic zone information may be defined as a center and radius of a circle. The data in the database 210 may be derived construction records, energy dispensing device installation records, conventional surveys, and the like. In some implementations, the information in the database 210 may be derived at least in part from satellite view and street view imagery. In some implementations, the zones may be encoded with or associated with additional data specific to a particular transaction. In some implementations, for a fueling station geographic object, the additional data may include, but is not limited to, a fuel station entity name, a fuel station address, a pump number, and the like.In some implementations, for a parking geographic object, the additional data may include, but is not limited to, a parking entity name, a parking address, a parking stall number, etc. It should be understood that the above descriptions of the additional data are merely examples, and the additional data may include less or more information to aid in completing a transaction associated with the geographic object.

[0050] In one implementation, the server 205 is a computer, either a physical machine or a virtual machine instance, or several integrated machines or virtual instances, that may be housed in a data center, such as the data center 120 from FIG. 1. A communication link 200 is provided between the server and other components of the system, namely, in some implementations, the mobile location device 10, the database 210, and the user 245. The communication link 200 may be a wireless communication link, a hardware communication link, or a combination of both types of communication, such as a combination of links 95, 105, and 115, or links 95, 105, 117, and 125 of FIG. 1. In the diagram of FIG. 2A, the mobile location device 10 communicates location data to the server 205. In some implementations, the location data may include position data, such as longitude and latitude coordinate data. In some implementations, the location data may include such coordinate data and additional data such as vehicle motion data (e.g., one or more of speed, acceleration, yaw rate, heading, etc.) and data related to obtaining the location data, such as an indicator of received GNSS signal strength (e.g., carrier to noise density ratio - which may be abbreviated as CN0, CNO, C / No, etc.), satellite system related data, source of the motion data (e.g., GNSS module derived motion data, sensor readings, etc.). In some implementations disclosed herein, a distinction is useful between motion data derived from GNSS signals and motion data that does not originate from vehicle resident or vehicle embedded sensors. For example, the GNSS data may be a source of vehicle speed, which may be referred to as GNSS derived velocity, or may be in the form of GNSS derived motion data. The GNSS derived velocity may be, for example, a derivative of GNSS acquired position over time, or may be determined from a Doppler frequency shift generated by vehicle motion relative to satellite positions.In contrast to GNSS-derived motion data, vehicle motion data may be obtained using vehicle-resident or vehicle-embedded sensors, such as inertial measurement sensors used by a MEMS inertial measurement unit processor, such as accelerometers, gyroscopes, magnetometers, or sensors used by an embedded vehicle motion detection (VMD) system, such as wheel rotation sensors, steering angle sensors, accelerometers, gyroscopes, and magnetometers, which may or may not be included in an embedded VMD implementation, or other sensors not mentioned. Vehicle motion data may also be referred to herein as non-GNSS motion data. In some implementations, communication of location data may occur for every location point determined by the mobile location device 10, or for some other data point interval or time interval (e.g., every other data point, every fifth data point, every second, every five seconds, etc.). In some implementations, such communication may be based on a query received by the mobile location device 10 for its current location, and the query response may include one or more location data points (e.g., 5 data points, 10 data points, etc.). In some implementations, such communication may result from the occurrence of a trigger event, such as a detected speed of zero indicating a stopped condition, or a detected speed below a certain speed threshold. In some implementations, a combination of intervals, queries, trigger events, and / or detected conditions may be used to initiate communication of location data. Upon receiving location data from the mobile location device 10, the server 205 may connect to the database 210 to obtain relevant information regarding a geographic object / zone that may be associated with the received location data point, and in some implementations data associated with the user 245, the user device 140 of the user 245, the vehicle 20, and / or its own service history (e.g., time of last refueling, amount of fuel received at last refueling, distance driven since last refueling, etc.).In some implementations, the service history may be used to generate a notification to the user 245 via the user device 140 that a refueling should be scheduled. In some implementations, the location data received from the mobile location device 10 and the energy dispensing device geolocation data included in the database 210 may be used to generate a list of possible fuel stations in proximity to the vehicle 20, which may be sent in a notification to the user 245 via the user device 140. In some implementations, upon a stalled condition or speed below a predetermined speed threshold and received location data corresponding to a geographic zone of the energy dispensing system (e.g., a fuel pump or charging station), the server 205 may communicate with the user 245 via the user device 140 to confirm that the vehicle 20 is located at a particular energy dispensing device to process the energy dispensing session.

[0051] In some implementations, a user 245 can install a mobile application 220 on their user device 140. The user 245 can configure an energy dispense management account associated with the user 245 to selectively enable receipt of energy dispense related notifications through the mobile application 220 or other notification mechanisms via a communication link 215. As described above for other communication links, the communication link 215 can be a wireless communication link, a hardware communication link, or a combination of both types of communication, such as a combination of links 145, 155, 165, and 125 of FIG. 1. In some implementations, the notification mechanism can be a notification via an installed mobile application 220. In some implementations, the notification mechanism can include notification via email 230, website 225, short message service (SMS) text 235, other communication means 240, or any combination of the above. The entity management energy dispensing automation system can provide a customer service function 250 that can be contacted by phone through link 260 or through link 255 via a software application to ask questions, resolve operational issues, and control the energy dispensing system. Thus, it should be appreciated that in some implementations, users 245 can customize their launch of energy dispensing sessions and communication settings.

[0052] FIG. 2B is a block diagram illustrating some implementations of various systems and methods further illustrating multiple mobile location devices and multiple user devices. The system elements of the mobile network 110, the data center 120, the Internet 130, and the mobile network 160, as well as the communication lines or links therebetween, are the same or similar to the system elements described above in FIG. 1. FIG. 2B further illustrates multiple mobile location devices, such as mobile location device 10a, mobile location device 10b, mobile location device 10c, and mobile location device 10d, operating within the system. Each of these mobile location devices 10a-10d is the same or similar to the mobile location device 10 described above. It should be understood that the system illustrated in FIG. 2B may support any suitable number of additional mobile location devices 10a-10d. In some implementations, a higher saturation of mobile location devices in any given geographic area provides better information to the server in the data center 120. This in turn allows the servers in the data center 120 to provide better information to the mobile location devices and elements in the system (e.g., mobile location devices 10a-10d and user devices 140a-140d). In some implementations having multiple different mobile networks 110, at least one of the mobile location devices 10a-10d may communicate with one of the different mobile networks. For example, mobile location device 10a may be located in the United States and communicate with a mobile network 110 located in the United States, while mobile location device 10d may be located in the United Kingdom and communicate with a different mobile network.

[0053] FIG. 2B further illustrates user device 140a, user device 140b, user device 140c, and user device 140d. Each of these user devices 140a-140d is the same as or similar to the user device 140 described above. It should be understood that the system illustrated in FIG. 2B may support any suitable number of additional user devices 140a-140d. Like user device 140, each user device 140a-140d is associated with at least one of mobile location devices 10a-10d. In some implementations, user device 140 may be associated with two or more mobile location devices 140a-140d. As described above, these associations may be stored in a server or database in data center 120. For example, if user device 140a belongs to user A who has two cars, user A may place mobile location device 10a in one car and mobile location device 10b in the other car. Thus, the system may associate mobile location device 10a and mobile location device 10b with user A's user device 140a.

[0054] Referring now to FIG. 3, a block diagram illustrates a system 300 including subcomponents of the mobile location device 10 in some implementations. In some implementations, the mobile location device 10 includes at least one processor / control unit / microcontroller 310. The processor 310 may be an application specific integrated circuit (ASIC) or a general purpose processor. The processor 310 directly or indirectly communicates with multiple other components shown in FIG. 3 that enable the mobile location device 10 to detect its position or location with high accuracy. The processor 310 may coordinate the functions of other modules described herein. The processor 310 may further execute algorithms to improve the accuracy of geolocation positioning and provide timely communication between the mobile location device and one or more servers. In some implementations, the processor 310 further operates a link between the low energy wireless communication module 370 and any external beacons located outside the vehicle 20.

[0055] In some implementations, the mobile location device 10 includes a geolocation positioning system 320 that is used to determine the location of the mobile location device 10 (and the vehicle 20 in which the mobile location device 10 resides) at any given time and in any geographic context. The geolocation positioning system 320 communicates with the processor 310. The geolocation positioning system 320 may comprise a custom processor capable of receiving and processing satellite signals, such as Global Navigation Satellite System (GNSS) signals (e.g., GPS, GLONASS, Galileo, etc.). The geolocation positioning system 320 may further include antennas, amplifiers, signal filters, etc., to efficiently process the received GNSS signals. The geolocation positioning system 320 transmits the GNSS signals to the processor 310 for further processing. In some implementations, the geolocation positioning system 320 comprises a reduced feature set to make the geolocation positioning system 320 affordable and functional for use in consumer devices. For example, in some implementations, the geolocation positioning system 320 lacks the ability to process raw GNSS data. In some implementations, the geolocation locating system 320 may lack the ability to reduce or eliminate the effects of multipath signal distortion on its own. When a reduced feature set geolocation locating system 320 is used, the reduced feature set may prevent the geolocation locating system 320 from operating properly in some areas, such as dense urban areas. For example, a vehicle 20 having a mobile location device 10 (including a reduced feature set geolocation locating system 320) may be located in a geographic zone associated with a fuel pump designated as fuel pump #1. Furthermore, the reduced feature set geolocation locating system 320 may, due to multipath signal distortion, erroneously determine its location as, for example, a geographic zone associated with fuel pump 3, or may not determine the geographic zone associated with the fuel pump at all.Even more expensive GNSS processors may not be able to mitigate against multipath signal distortions by themselves. However, when the geolocation positioning system 320 is configured with certain other systems or features discussed below, the geolocation positioning system 320 provides high accuracy location detection despite the reduced feature set of the geolocation positioning system 320. The reduced feature set also allows the geolocation positioning system 320 to use less power in operation. In some implementations, the geolocation positioning system 320 detects the location of the mobile location device 10 within a range of approximately 4 meters or less, as well as energy dispensing related events. In some implementations, the geolocation positioning system 320 may be included in a vehicle system, and the processor 310 may communicate and receive GNSS data from the vehicle system (not shown).

[0056] In some implementations, various solutions may be employed to help provide the desired positioning or location accuracy of the mobile location device 10 using GNSS correction data. For example, a differential GPS system aided by data received from a Continuous Observed Reference Station (CORS), such as that described in U.S. Pat. No. 5,490,073 (incorporated herein by reference in its entirety), may provide assistance for determining positioning in dense urban environments. Currently, there are several publicly operated CORS networks in the United States, such as NYSnet in New York State. Data from the CORS network may be obtained by the geolocation positioning system 320 in the mobile location device 10 via established protocols, such as the RTCM 10403.1 standard or other suitable standards. In some implementations, real-time kinematic data and raw data from the receiver are used to evaluate pseudoranges and other variables in custom algorithms that may be implemented in ASICs or software to determine a more accurate location of the mobile location device 10 (and vehicle 20). In some implementations, alignment to road maps, assisted GPS, and other suitable techniques may be used to assist in determining a desired positioning or location accuracy of the mobile location device 10.

[0057] In some implementations, the system 300 further includes a MEMS system 330. The processor 310 communicates with the MEMS system 330. In some implementations, the system 330 is an inertial measurement sensor (IMU) that includes at least an accelerometer and a gyroscope. The MEMS system 330 can measure linear and angular motion of the mobile location device 10. In some implementations, the MEMS system 330 further includes a magnetometer. The MEMS system 330 may include other suitable sensors. When the processor 310 combines data from the geolocation locating system 320 and the MEMS system 330, the processor 310 can more accurately determine the location of the mobile location device 10 within the vehicle 20. This increased accuracy assists in establishing energy dispensing events and energy dispensing sessions while using the reduced feature set geolocation locating system 320. In some implementations, when the geolocation positioning system 320 is not operating properly (e.g., when satellite signals cannot be received when under a bridge or in a tunnel), data from the MEMS system 330 may augment or replace data from the geolocation positioning system 320 to assist in establishing vehicle location for transaction events such as energy dispensing events, energy dispensing sessions, parking events, parking sessions, etc. In some implementations, the system 300 of the mobile location device 10 may not include the MEMS system 330. In some implementations, the MEMS system 330 may be included in a vehicle system and the processor 310 may communicate or receive MEMS data from a vehicle system (not shown), such as a vehicle motion detection or range (VMD) system.

[0058] In some implementations, the processor 310 may communicate with the vehicle's systems via a controller area network ("CAN bus"). It should be understood that the processor 310 may receive any suitable available data from the vehicle's existing systems and use this data to determine the location of the vehicle. In some implementations, the mobile location device 10 may be configured as an embedded system within the vehicle or is otherwise integrated into the vehicle. In some such implementations, the features of the processor 310 described herein may be integrated into the vehicle's processor. In some such implementations, one or more of the mobile location device 10 systems shown in FIG. 3 may be separate elements already present in the vehicle, and the processor 310 may communicate with these various systems to obtain the appropriate data to perform the high accuracy location determination functions described herein.

[0059] In some implementations, the processor 310, or an AISC or processor not shown, may be configured to include an estimation filter, such as a Kalman filter, configured to determine and maintain a predictive location estimation model that estimates a current position based on input streams of data received from the GNSS module and the MEMS (or VMD) system. In some implementations, a novel dual mode Kalman filter including a fixed mode and a dynamic mode may be used, as described later in this specification.

[0060] In some implementations, the system 300 further includes a power circuit system 340. The power circuit system 340 may include one or more batteries, charging ports, electrical outlets, and power management integrated circuits. The power circuit system 340 provides power to various components of the system 300 in the mobile location device 10. In some implementations, the power circuit system 340 monitors the power reserve and communicates with the processor 310 to determine when to reduce operation of certain system 300 components to conserve power or when to shut down the mobile location device 10. In some implementations, the mobile location device 10 uses the battery to keep some operating information in a buffer to allow the mobile location device to start up quickly (instead of a cold start, where the mobile location device 10 must go through a longer boot / initialization procedure to be usable). In some implementations, the mobile location device 10 configured with an estimation filter may use the battery to hold the predictive location estimation model therein. In some implementations, the mobile location device 10 includes a second battery to hold satellite almanac information in a RAM buffer. This allows the mobile location device 10 to power up without having to re-establish a first fix time with the satellites.

[0061] In some implementations, the system 300 further includes a wireless communication system 350. The wireless communication system 350 provides a communication link between the mobile location device 10 and at least one server (through a communication link discussed herein). The wireless communication system 350 may include a cellular data processor, an antenna, a SIM card (and / or eSIM functionality), and other components necessary to communicate with a mobile network, such as the mobile network 110. In some implementations, communication from the processor 310 (through the mobile network 110) to the server can be established according to a predetermined protocol, for example, through an Internet connection based on the HTTP protocol and HTTPS extension protocol (e.g., GET and POST request methods), through a protected virtual private network (VPN), or through a combination of both. For example, the mobile location device 10 and the server in the data center 120 can be connected through a VPN tunnel created using the processor 310 communicating with the wireless communication system 350. In some implementations, the connection can be periodically refreshed and messages reach both destinations (the mobile location device 10 and the server) through open sockets.

[0062] In some implementations, system 300 further includes a human interface device system (HID) 360. HID 360 may include one or more buttons that a user can press. HID 360 may include one or more LED lights that can provide useful system status information to the user. In some implementations, HID 360 includes a screen that can generate and display messages to the user (e.g., reporting battery life, reporting system status, reporting energy dispensing device zone information, etc.). HID 360 communicates with processor 310 to receive user input or provide information to the user.

[0063] In some implementations, the system 300 further includes a low energy wireless communication system 370. The low energy wireless communication system 370 may comprise a processor, an antenna, and other components necessary to communicate with other low energy wireless devices. The low energy wireless communication system 370 may be configured to communicate via a predetermined protocol, such as IEEE 802.15 (e.g., Bluetooth). The low energy wireless communication system 370 may communicate with the processor 310 of the system 300 in the mobile location device 10. In some implementations, the low energy wireless communication system 370 may communicate with remote parking enforcement devices, energy dispensing devices, parking structure beacons, energy dispensing station beacons, and other similarly configured wireless devices, which may facilitate location detection at a given location with little or no satellite system signals (e.g., in locations where GNSS signals cannot be acquired).

[0064] 4, 5 and 6 are block diagrams showing further details regarding some of the components of the system 300 in the mobile location device 10 discussed in connection with FIG.

[0065] Now referring to FIG. 4, several implementations of signaling between certain components of the mobile location device 10 are shown. As shown in FIG. 3, a processor 410 (also shown in FIG. 3 as processor 310) communicates with several different components. In various implementations, the processor 410 manages power and collects and uses information from the different modules shown in FIG. 4. The processor 410 communicates with a GNSS module 420 (which is a component of the geolocation positioning system 320) via a universal asynchronous receiver transmitter (UART). Information about coordinates from the GNSS module 420 is transmitted to the processor 410 via the UART. The GNSS module 420 may, in some implementations, generate a 1 Hz pulse and transmit the 1 Hz pulse to the processor 410. In some implementations, the 1 Hz pulse may be used to synchronize data from different modules or components communicating with the processor 410.

[0066] Also shown is a MEMS navigation module 425 (a component of the MEMS system 330 of FIG. 3), a cellular module 435 (a component of the wireless communication system 350 of FIG. 3), and a Bluetooth module 440 (a component of the low energy wireless communication system 370 of FIG. 3). The MEMS navigation module 425 is an inter-integrated circuit (I 2 The MEMS navigation module 425 communicates with the processor 410 via a UART, while the cellular module 435 and the Bluetooth module 440 communicate with the processor 410 via a UART. It should be appreciated that the modules described herein may communicate with the processor 410 using any suitable method. For example, the MEMS navigation module 425 communicates with the I 2The processor 410 transmits inertial measurement data to the processor 410 via UART, which can be used to help the processor 410 correct the coordinate data it obtains from the GNSS module 420. The processor 410 transmits data to the cellular module 435 via UART, through which the mobile location device 10 communicates with a server to transmit the current state of the mobile location device 10, such as the coordinates and status of the mobile location device 10. In some implementations, the GNSS module 420 communicates with the cellular module 435 via UART to provide the GNSS correction data to the GNSS module 420. 2 The mobile location device 10 may communicate with the cellular module 435 via a UART. In some implementations, firmware on the mobile location device 10 may be updated through the cellular module 435 in communication with the processor 410. In some implementations, the Bluetooth module 440 communicates with the processor 410 via a UART to establish a connection between the mobile location device 10 and the user device 140 of the user.

[0067] The USB connector 445 is shown as being connected to the processor 410 via the Universal Serial Bus standard. In some implementations, the mobile location device 10 may not include a USB connector 445. In some implementations, the mobile location device 10 includes other types of suitable connectors. In various implementations, the USB connector 445 can be used to power the mobile location device 10, charge batteries within the mobile location device 10, and update firmware on the mobile location device 10.

[0068] The power management IC 430, linear regulator 450, linear regulator 455, linear regulator 460, and power key 465 (components of the power circuit system 340 of FIG. 3) communicate with the processor 410. The processor 410, in some implementations, can use logic levels to control the power of the device, as well as the power to the different components shown in FIG. 4. For example, the processor 410 can turn off the entire mobile location device 10, or can turn off the output of the power linear regulators 450, 455, and 460 to individual modules (power connections between modules are shown in FIG. 5). The processor 410 can also turn off the cellular module 435, in some implementations, by sending a logic level signal to the power key 465. In some implementations, the ability to selectively shut down different modules creates a very power-efficient device.

[0069] FIG. 5 shows a block diagram of several implementations of a power circuit system 500 (corresponding to the power circuit system 340 of FIG. 3) showing the power supply interconnections. In one implementation, the heart of the power supply is a power management integrated circuit (IC) 505 configured to receive power from both a USB connector 510 (corresponding to the USB connector 445 of FIG. 4) and a battery 515 and dynamically switch between the two power sources. In some implementations, the power management IC 505 charges the battery when the USB connector 510 is used for power. In the illustrated implementation, the cellular module 520 (corresponding to the cellular module 435 of FIG. 4) is powered directly from the power management IC 505. The other illustrated modules processor 530, MEMS navigation module 540, GNSS module 550, and Bluetooth module 560 are all powered via an LDO (low dropout) linear regulator 525, a linear regulator 535, a linear regulator 545, and a linear regulator 555. As mentioned above, the modules of FIG. 5 correspond to those described above in FIG. 4, which are components of the system discussed in FIG. 3. As also described above in relation to FIG. 4, this configuration allows the processor 410 to control the power provided to the various modules to ensure efficient use of power. For example, the processor 410 may shut down the GNSS module 550 when the processor 410 determines that the mobile location device 10 is in a location where it cannot receive GNSS signals (e.g., a parking structure, in a tunnel, etc.). The processor 410 may be configured to selectively shut down different modules under different trigger conditions to ensure maximum battery life or most efficient power consumption of the mobile location device 10. The trigger events may include events such as the expiration of a timer after a shut down condition is detected by MEMS data and / or GNSS data.

[0070] FIG. 6 shows a block diagram of some implementations of a human interface device (HID) system 600 (corresponding to HID 360 of FIG. 3) illustrating human input and feedback mechanisms of the mobile location device 10. In the illustrated implementation, a processor 610 (corresponding to processors 310, 410, etc.) is connected to buttons 620, 625, 630, and LEDs 635. It should be understood that fewer or more buttons may be added to the mobile location device 10. In some implementations, multiple LED lights are used to provide information to a user of the mobile location device 10. In some implementations, a display screen may be included in addition to or instead of the LEDs 635. In the illustrated implementation of FIG. 6, button 620 is associated with turning on power to the mobile location device 10, button 625 is associated with triggering an internal diagnostic test of the mobile location device 10, and button 630 is associated with resetting the mobile location device. The buttons may be configured to trigger any suitable function. In some implementations, one or more buttons may be associated with multiple different functions. In some implementations, the reset button 630 may be recessed from the surface of the mobile location device 10 to prevent accidental activation. In some implementations, the LED 635 may provide informational status to the user in a variety of different ways. In some implementations, the LED 635 may light a certain color when the device is powered on, light a different color when a test is being performed, and light yet another color when a reset is being performed. In some implementations, the processor 610 may blink the LED 635 in different patterns to alert the user of different events (e.g., communication mode, low battery mode, charging mode, error conditions, etc.).

[0071] Turning now to the operation of the mobile location device 10, as mentioned above, the mobile location device 10 can be configured with different GNSS modules capable of refining various levels of coordinate accuracy. As mentioned above, some applications of location or positioning data require high accuracy. For example, some require positioning accuracy of approximately 4 meters or less. Obtaining this level of accuracy can be difficult in certain situations, such as dense urban settings, whether using expensive or less expensive GNSS modules. Obtaining stable GNSS data in dense urban settings poses several challenges. Tall buildings in "urban canyons" completely block GNSS signals from some satellites, resulting in poor satellite geometry. Parking structures and island canopies of energy dispensing devices can disrupt GNSS signals. GNSS signals can be reflected by various surfaces, leading to non-line-of-sight (NLOS) GNSS signal reception, as well as multipath contamination of the GNSS signals. When the GNSS receiver is placed inside the vehicle, the view of the sky above can be further obstructed by the roof of the vehicle, and multipath effects are enhanced by bodies and objects present within the vehicle. When moving below a threshold speed (e.g., 2 km / h, 5 km / h, or some other suitable speed), the GNSS signal may also suffer from drift errors (e.g., the GNSS signal indicates a nearby position other than the actual position of the vehicle). Many GNSS modules and systems (e.g., GNSS receivers and antennas) are susceptible to the aforementioned effects. The aforementioned effects result in long location detection convergence times and coordinate jumps that can exceed 10 meters. Some high-end GNSS receivers are configured to mitigate some of the effects of the aforementioned adverse effects at the hardware level. However, such high-end GNSS receivers are prohibitively expensive, prohibitively large, require high energy consumption, and still suffer from the same problems. These high-end GNSS receivers are not available for mass-market platforms due to the high cost, unacceptable physical size, and high energy consumption of these devices.Also, in dense urban settings, even high-end GNSS receivers are often unable to overcome problems resulting from poor satellite geometry, NLOS signal reception, multipath effects, and slow drift effects to provide coordinate outputs of sufficient integrity (e.g., on the order of 4 meters or less) to be useful for location systems requiring highly accurate position detection.

[0072] Therefore, there is a demand for a high-precision location (or position) detection system that can use an inexpensive low-end GNSS receiver. As disclosed in FIG. 7 and FIG. 8, the disclosure herein details a high-precision location (or position) detection system that can use an inexpensive GNSS receiver, and while high-precision location detection of approximately 4 meters or less can be achieved using an estimation filter as disclosed, the detection system can be low-cost, small size, and low energy consumption. In some implementations, the GNSS data stream can be supplemented with at least one or more other location data sources to be low-cost, small physical size, and low energy consumption while achieving high-precision location detection of approximately 4 meters or less. In some implementations, the high-precision location (or position) detection system can use both an estimation filter and supplementing the GNSS data stream with other data sources as disclosed herein, and can achieve high-precision location detection of approximately 4 meters or less but still be low-cost, small physical size, and low energy consumption.

[0073] FIG. 7 is a flow chart of some implementations illustrating the signal processing path of a process 700 for acquiring a location data stream in a mobile location device 10. One or more processors in the mobile location device 10 convert the location data stream into high-precision location data associated with the mobile location device 10. In some implementations, the mobile location device 10 acquires the location data stream from multiple sources. The sources may include GNSS signals 705 from satellites such as GPS and GLONASS, GNSS correction data 720, and inertial and / or other sensor measurement data of an embedded VMD / MEMS data module 725, and vehicle motion data may come from an embedded vehicle motion detection ("VMD") system (not shown) and / or MEMS module (MEMS navigation module 425 as shown in FIG. 4) of the mobile location device 10. In some implementations, when the mobile location device 10 is not an embedded system in the vehicle and does not have access to vehicle motion data (e.g., wheel speed data, yaw rate, etc.) from vehicle sensors, the VMD / MEMS data module 725 is a MEMS module that does not have access to the vehicle's VMD. In some such implementations, the MEMS module can be used to provide vehicle speed from accelerometer data and yaw rate from the gyroscope. In some such implementations, the MEMS-based vehicle speed data can be used as a backup or alternative to GNSS-derived speed data from GNSS data. In some implementations, when the mobile location device 10 is not an embedded system within the vehicle, the VMD / MEMS data module 725 can have access to the vehicle's VMD, such as through the vehicle's CAN bus. In some such implementations, one or more items of vehicle motion data can be derived from the vehicle's sensors, such as vehicle wheel speed (e.g., for accurate speed data) and steering angle (e.g., which can be used to calculate yaw rate).In some implementations, when the mobile location device 10 is an embedded system within a vehicle, the VMD / MEMS data module 725 may not require a separate MEMS module. That is, in some such implementations, the VMD / MEMS data module 725 may obtain non-GNSS derived motion data from one or more various sensors embedded in the vehicle that already provide wheel speed data, yaw rate data, and the like. In some implementations, the mobile location device 10 may also obtain GIS data (not shown). The mobile location device 10 may obtain other suitable data input streams in some implementations. It should be understood that some or all of the location data input streams shown in FIG. 7 may not be used or obtained in some implementations. When available and as needed, the GNSS module 715 obtains GNSS signals 705 from available satellites through the antenna 710. The GNSS signals 705 may include information such as, but not limited to, a GPS timestamp; latitude, longitude, height; solution status; ground speed; and azimuth.

[0074] In some implementations, the GNSS module 715 may also obtain GNSS correction data 720, although this is not required. Although not shown, in some implementations, the GNSS correction data 720 may be obtained from a processor, such as the processor 310 of the mobile location device 10. The processor 310 may obtain such GNSS correction data 720 via a server in the data center 120 or a server connected to the Internet 130 through the mobile network 110. In some implementations, the GNSS correction data 720 may be received from other sources, such as fixed ground-based reference stations. The GNSS correction data 720 may include differential GPS data, ephemeris, almanac, precise time, satellite status, and any other suitable data points. As discussed further below, a processor (e.g., the processor 310) of the mobile location device 10 may apply the GNSS correction data 720 to the received GNSS signals 705 to calculate and determine more accurate GNSS location data for the mobile location device 10.

[0075] The embedded VMD / MEMS data module 725 (corresponding to the MEMS system 330 and the MEMS navigation module 425, and / or the vehicle's embedded VMD system) includes sensors such as accelerometers and gyroscopes and may include sensor data similar to MEMS data in the case of VMD, and may include vehicle motion data associated with sensors coupled to the vehicle mechanical system, such as wheel rotation (wheel speed) and steering angle (turning radius). In some implementations, the embedded VMD / MEMS module 725 acquires vehicle motion data such as linear acceleration, magnetic field, and angular velocity. In some implementations, the MEMS system 330 may include at least three different channels of each measurement to acquire three-dimensional inertial motion data. In some implementations, as described above, the acceleration provided by the MEMS system 330 can be used to calculate the vehicle's velocity, which is a non-GNSS derived velocity, which is the vehicle motion data velocity. In some implementations, the calculated vehicle velocity can be used as velocity information provided to a dual mode Kalman filter described below. In some implementations, the calculated vehicle speed from the MEMS system 330 is provided to the dual mode Kalman filter and used in place of GNSS-derived speed information obtained from the GNSS module (e.g., when the GNSS data cannot be trusted because it has a highly associated level of uncertainty, as can be determined from the CN0 data).

[0076] The GNSS module 715 and the embedded VMD / MEMS data module 725 send their data to a GNSS / VMD-MEMS data synchronization block 730 that synchronizes the data streams, and the synchronized GNSS / VMD-MEMS data stream 740 can be input to an estimation filter, such as a Kalman filter 750, that can estimate a final set of coordinate data 760. It should be understood that final with respect to the final set of coordinate data 760 is not final in the sense that no additional coordinate data is generated. In some implementations, the estimation filter generates the coordinate data continuously. In some implementations, the data (e.g., the GNSS / VMD-MEMS data stream 740) that is fed to an estimation filter, such as the Kalman filter 750, may be assigned a weight or confidence value that the estimation filter can use to determine how the data is used to generate the coordinate data. As the reliability of the data decreases, the estimation filter may become less reliant on the data provided to generate the coordinate data. For example, the velocity pre-processor 745 may determine a distributed position measurement (VPMV) based on CN0 data obtained from the received GNSS data. As the CN0 value decreases, the VPMV value may increase along a particular scale. In some implementations, the VPMV is provided to the estimation filter along with the GNSS data. As the VPMV value increases for the GNSS data, the estimation filter may become less reliant on the GNSS data and more reliant on the VMD-MEMs data to generate the coordinate data. In some implementations, for example, when the CN0 value of the GNSS data is below a predetermined threshold (e.g., 20 or some other suitable number), the velocity pre-processor 745 may determine a VPMV value of the GNSS data that is high enough that the estimation filter may substantially ignore the GNSS data when generating the coordinate data.

[0077] In some implementations where the GNSS data is substantially ignored, for example, the velocity pre-processor 745 may determine whether to use velocity data from the GNSS data (GNSS-derived velocity) or velocity data from the MEMS system 330 (vehicle motion data velocity). For example, if the CN0 data obtained from the GNSS data indicates that the GNSS data is below a threshold level of uncertainty or that the VPMV is above a threshold, the velocity pre-processor 745 may cause the velocity data calculated from the MEMS system 330 to be provided to the dual mode Kalman filter 750. For example, the processor of the vehicle motion device 10 may calculate velocity data from acceleration data obtained from the MEMS system, which velocity data may be used by the Kalman filter 750 in its generation of coordinate data on the velocity data obtained from the GNSS data.

[0078] In some implementations, when the GNSS data is derived from two or more GPS satellite systems, the process of determining whether CN0 is below the uncertainty threshold level is based on averaging two or more CN0 data points from at least two of the GPS satellite systems used to provide the GNSS data. In some implementations, the CN0 value used to determine whether CN0 is below the uncertainty threshold level is calculated using an average CN0 value from each satellite system used to generate the GNSS data. In some implementations, the CN0 value used to determine whether CN0 is below the uncertainty threshold level is calculated using an average CN0 value from a subset of the satellite systems used to generate the GNSS data. Although the speed pre-processor 745 is shown as separate from the dual mode Kalman filter 745, in some implementations, the functionality of the speed pre-processor 745 may also be integrated into the dual mode Kalman filter 750. It should be appreciated that when vehicle wheel speed data is available (e.g., when VMD information can be obtained), the speed pre-processor 745 may not be needed or may default to using the vehicle wheel speed data over the speed data from the GNSS data or the speed data calculated from the MEMS system 330. The final coordinates may be continuously output by the Kalman filter 745 as a coordinate data stream 760, which in some implementations may be set to an output rate of 1 Hz, for example, based on the GNSS module 715 having a raw data output rate of 1 Hz. In some implementations, the estimation filter may be a novel dual mode Kalman filter 750 discussed in connection with FIG.

[0079] It should be understood that a processor, such as the processor 310 in the mobile location device 10, is responsible for and may be configured to receive data streams from the GNSS module 715 and the embedded VMD / MEMS data module 725, perform synchronization, and perform calculations that may include Kalman filter 750 calculations. In some implementations, the processor 310 may receive precise GNSS correction data 720 and apply corrections to GNSS signals from the GNSS module 715 without routing the precise GNSS correction data 720 to the GNSS module 715.

[0080] FIG. 8 is a flow chart of a process 800 illustrating some implementations of systems and methods for capturing and calculating high-precision coordinate data of a mobile location device (e.g., mobile location device 10). At block 805, in some implementations, a processor, such as the processor of mobile location device 10, may receive GNSS data and non-GNSS motion data (e.g., vehicle motion data received from MEMS and / or VMD). In some implementations, for example, GNSS data may be received from GNSS module 725 and non-GNSS motion data may be received from VMD / MEMS data module 725. As shown in FIG. 7, GNSS module 715 may receive GNSS satellite data or GNSS satellite data plus correction data from multiple other sources in some implementations. When more than one source of GNSS data is received, the processor of the GNSS module may correct the GNSS satellite data with any received correction data. At block 810, in some implementations, as described above, the GNSS module obtains timing data from the GNSS data and uses this data to generate synchronized timing pulses. In some implementations, the processor of the mobile location device 10 provides a synchronization timing pulse. The synchronization timing pulse may be provided using any other suitable mechanism. At block 810, in some implementations, the processor of the mobile location device 10 uses the timing pulse to synchronize the received GNSS data and non-GNSS motion data. In some implementations, the processor of the mobile location device 10 may also pre-process the GNSS and non-GNSS motion data to determine a source of speed data to use. For example, the processor of the mobile location device 10 may determine whether to use speed data from the GNSS data or to calculate speed data points from the non-GNSS motion data, as discussed in connection with the speed pre-processor 745 of FIG. 7.

[0081] At block 820, the synchronized data values ​​are input to a Kalman filter. In some implementations, the Kalman filter is a novel multi-mode Kalman filter. In some implementations, the multi-mode Kalman filter includes a first mode and a second mode. In some implementations, the Kalman filter can include fewer or additional modes. In some implementations, the first mode of the Kalman filter is a dynamic mode in which the Kalman filter generates predicted position coordinate data for the vehicle and adjusts the probabilities of a model used to generate the next predicted position coordinate data based on the received GNSS data and non-GNSS motion data. In some implementations, the second mode of the Kalman filter is a fixed-position mode in which certain data from the GNSS data and non-GNSS motion data can be set to the same or different predetermined values, and the predetermined values ​​are independent of the data received from the GNSS module or the VMD / MEMS data module. In some implementations, certain data from the GNSS data and non-GNSS motion data is modified or replaced for the fixed-position mode of the Kalman filter. The fixed position mode is so referred to due to one or more types of data that may be set to a predetermined value rather than relying on dynamic values ​​obtained from the GNSS module or the VMD / MEMS data module. In some implementations, the predetermined value may be zero or some other suitable value. In some implementations, a velocity value used by the Kalman filter to generate the vehicle location coordinate data may be set to a predetermined value (e.g., zero or some other suitable number). In some implementations, setting the velocity value to a predetermined value may invalidate or otherwise modify a velocity value provided by the GNSS module or a velocity provided by the VMD / MEMS data module. In some implementations, a yaw rate used by the Kalman filter to generate the vehicle location coordinate data may be set to a predetermined value (e.g., zero or some other suitable number).In some implementations, the yaw rate value may be set to a predetermined value to override or otherwise modify the yaw rate value provided by the VMD / MEMS data module. In some implementations of the fixed mode, the heading value may be set to a fixed value. It should be appreciated that other suitable values ​​may be modified for the fixed mode of the Kalman filter.

[0082] At block 825, when the current speed falls below a predetermined threshold speed (e.g., 2 km / h, 5 km / h, or some other suitable speed), the Kalman filter switches or changes to a second mode or a fixed mode. For example, as shown in block 830, in some implementations, the Kalman filter updates using the fixed mode and generates / outputs coordinate data based on the updated predictive model maintained by the Kalman filter. In some implementations, for the fixed mode of the Kalman filter 750, the velocity and yaw (e.g., rotational rate) are set to zero and the heading is fixed. For example, in some implementations, the heading can be fixed to the last known heading output by the Kalman filter 750 when the current speed is determined to fall below the predetermined threshold speed. In some implementations, when the current speed is determined to fall below the predetermined threshold speed, the Kalman filter may remain in the fixed mode until a trigger event occurs. In some implementations, the trigger event can be a predetermined period of time. In some implementations, the triggering event may be determining that the speed of the vehicle exceeds a threshold speed. In some implementations, when the triggering event occurs, the Kalman filter may return to a dynamic mode (e.g., the first mode). In some implementations, when a fixed position mode is triggered for the Kalman filter, the mobile location device 10 may capture a predetermined number of Kalman filter coordinate outputs from block 830. In some implementations, the predetermined number of captured coordinate outputs is five coordinate outputs from the Kalman filter. In some implementations, the predetermined number may be less than five or more than five. In some implementations, the coordinate outputs using the fixed position mode of the Kalman filter are used to determine services (e.g., parking sessions, vehicle refueling sessions, vehicle charging sessions, curbside pickup sessions, etc.) that may be triggered based on the vehicle location.

[0083] Returning to block 825, in some implementations, when the current speed is equal to or greater than a predetermined threshold speed, such as 2 km / h (or some other suitable threshold), the Kalman filter in block 835 updates using a dynamic mode and outputs coordinate data based on the updated predictive model maintained by the Kalman filter. In some implementations, for the dynamic mode of the Kalman filter 750, the speed and rotation rate are not set to zero, and the heading is not fixed (e.g., they maintain their values ​​as inputs in block 820, such as from GNSS data and non-GNSS motion data). In block 840 of some implementations, the coordinate data output based on the updated predictive model of block 830 or block 835 may be stored in memory, or in some implementations may be transmitted to a geomapping server as shown in block 850.

[0084] In some implementations, the Kalman filter assigns different weights to data inputs (e.g., GNSS data and non-GNSS motion data) based on an uncertainty matrix calculated to minimize the probabilistic prediction model. For example, if the mobile location device is under a bridge and the GPS signal is weak (as indicated by CN0, carrier-to-noise density data value), the Kalman filter may assign a lower weight to the GNSS data and a higher weight to the MEMS data for purposes of calculating the coordinate data of the mobile location device. In some implementations, when the Kalman filter is operating in a fixed position mode (e.g., because the speed is below a predetermined threshold) and the GNSS data integrity exceeds a predetermined integrity level (e.g., the associated uncertainty is low), the Kalman filter may revert to a dynamic mode even if the vehicle speed is below the threshold speed. In some implementations, the Kalman filter determines that the GNSS data integrity exceeds a predetermined integrity level by examining the latitude and longitude data provided by the GNSS module. In some such implementations, if a threshold amount of consecutive latitude and longitude data points (or latitude and longitude data points over a given time period) from the GNSS module indicates that the vehicle is moving, the Kalman filter determines that the GNSS data should be trusted and that the Kalman filter should return to a dynamic mode (e.g., a first mode). In some implementations, the Kalman filter can remain in the reverse dynamic mode for a predetermined period of time, or the GNSS data integrity falls below a predetermined integrity level. The Kalman filter can be kept in the dynamic mode from a fixed mode based on other suitable triggering events.

[0085] The Kalman filter may generate coordinate data including a timestamp, latitude, longitude, and ellipsoidal height. Other suitable outputs can be calculated based on the location data input. In some implementations, the Kalman filter may generate coordinate data with fewer data items.

[0086] In some implementations, obtaining a single coordinate data point may be sufficient for location detection purposes. In some implementations, the process 800 may operate in a loop as shown in FIG. 8, which maintains state variables and other values ​​such as weights of the Kalman filter, thereby maintaining a track over the current location and eliminating start-up initialization time for the filter to re-establish its state variables and other values ​​the next time estimated location data is needed. Such initialization process is not described in detail, but in some implementations may be represented as a minimum number of cycles (loops) of the process 800. As mentioned above, in block 850, the processor of the mobile location device may transmit the coordinate data point to a local system or module, or to a remote system such as a geo-mapping server as shown, for use in the coordinate data determined by the mobile location device 10. In some implementations, such transmission of the coordinate data output from the Kalman filter process may occur at every point or at some other interval of calculated data points or time (e.g., every other data point, every fifth data point, every 20th data point, etc.). In some implementations, such transmission may be based on a current location query received by the processor. In some implementations, such transmission may be based on a trigger event, such as a detected speed of zero indicating a stationary condition, or a system state, such as a speed below a certain threshold (as discussed in block 825). In some implementations, a predetermined number of data points may be transmitted in response to a trigger event, such as 5 data points, 10 data points, or some other suitable number of data points. In some implementations, a combination of intervals, queries, trigger events, and / or system states may be used to transmit the current coordinate data.

[0087] It should be understood that high-precision location detection of a mobile location device may not have GNSS data available for location detection in some implementations. Although not shown, the process 800 for determining the geographic position of a mobile location device may use other sources of location data. For example, low energy radio beacons may be installed throughout a geographic area. These low energy radio beacons may broadcast location information similar to GNSS data obtained from satellites. In one implementation, one or more location beacons may be installed at a parking structure or energy dispensing station. Thus, when a mobile location device enters such a station and other sources of location data are lost, the mobile location device can receive location data broadcast from one or more beacons to determine that the mobile location device is at a particular energy dispensing station. Similarly, cellular tower triangulation and IEEE 802.11 (wifi) triangulation can be used when other location data is not available.

[0088] It should be appreciated that low-cost but highly accurate location detection can be used in several different systems that require geographic location information. In some implementations, as described above, an automated energy dispensing and payment system may require highly accurate location detection to determine whether a mobile location device is within a geo-located zone associated with a particular energy dispensing device. In some implementations, an automated parking and payment system may require highly accurate location detection to determine whether a location device is parked within a legal parking zone. In some implementations, highly accurate location detection is useful for improved direction systems to avoid providing erroneous directions (more accurate location information can be fed to a mobile phone mapping application to obtain better directions). In some implementations, mobile location devices can be installed in company vehicles to collect and provide accurate data for managing the company vehicles. In some implementations, an automated curbside pickup system may require highly accurate location detection to determine whether a location device is located within a particular geo-located pickup zone. In some implementations, the mobile location devices can interact with a toll passage system to provide toll payment and reduce the number of devices that users must maintain in their vehicles. In some implementations, the mobile location device and the high accuracy location detection system may track a variety of different data points regarding vehicle usage for insurance data analysis. The above list of uses for the high accuracy location detection system and method are merely examples, and other suitable users are contemplated.

[0089] For purposes of further discussion, FIGS. 9-15 describe in greater detail several implementations that provide for the use of a low-cost, highly accurate location detection system.

[0090] 9 is a flow chart depicting some implementations of a mobile location device 10 connecting with a geo-mapping server in a data center 120 for secure communication in a process 900. For security purposes, before the process 900 begins, the mobile location device 10 may be assigned and configured with certain identification information, such as a private Internet Protocol (IP) address, a device ID, a subscriber identification information in a subscriber identity module (SIM) chip (or eSIM), and information on how to contact the geo-mapping server. The geo-mapping server or some associated server or database is configured to store the assigned private IP address and SIM chip information associated with the mobile location device for later verification during the registration and communication process.

[0091] At block 910, a mobile location device (such as mobile location device 10) registers with a local wireless network (such as mobile network 110). In some implementations, this may occur automatically when the mobile location device is powered on or when a user presses a button on the mobile location device. In some implementations where the mobile location device operates on a GSM network, the mobile location device may perform an International Mobile Subscriber Identity (IMSI) attach procedure. However, any suitable registration procedure may be employed to register the mobile location device with the local wireless network. In one implementation, the local wireless network is configured to recognize some unique identification information associated with the mobile location device so that it knows that communication traffic from the mobile location device is routed to the geo-mapping server in a predetermined manner. In one such implementation, a VPN tunnel is set up by the local wireless network to carry communication traffic from the mobile location device to the geo-mapping server in the data center 120.

[0092] In some implementations, once a connection to the local wireless network is established, the mobile location device randomly (or pseudo-randomly) selects a logical socket communication port number (e.g., one of the Transmission Control Protocol (TCP) port numbers) in block 920 and opens the randomly selected port for communication with the geo-mapping server. In some implementations, only the mobile location device knows the randomly selected communication port number from the beginning. In this way, if the mobile location device receives a message or other communication request on any other communication port number, the mobile location device will know that such communication request is unauthorized. In some implementations, if an unauthorized communication request is received on an unselected communication port number, the mobile location device may turn off hacking attempts, denial of service attempts, or other undesirable intrusions or communications.

[0093] In some implementations, the mobile location device sends a message including a randomly selected communication port number, a mobile location device ID, through a mobile network (e.g., a local wireless network) to the geo mapping server in block 930. It should be understood that in some implementations, a different set of information, such as a SIM chip ID (or eSIM ID) and a private IP address, may be sent to the geo mapping server to establish a connection. As described above, the message in block 930 may be sent through the mobile network through a VPN. The VPN encrypts traffic communication between the mobile location device and the geo mapping server to prevent other hosts or endpoints on the mobile network from discovering the mobile location device or the geo mapping server (e.g., from brute-force pinging a set of IP addresses or subnets). However, in some implementations, the communication traffic between the mobile location device and the geo mapping server on the mobile network may not go through a VPN. In some implementations, the mobile location device and the geo mapping server may encrypt the communication traffic sent through the mobile network or may send the communication without encryption.

[0094] At block 940, the geomapping server, in some implementations, receives a message from the mobile location device over at least the mobile network. At block 950, the geomapping server may open a secure communication port (e.g., a TCP port) for communication with the mobile location device over at least the mobile network. In some implementations, the geomapping server may also communicate with a user device (e.g., user device 140) over an Internet connection (e.g., through Internet 130).

[0095] In some implementations, the geo-mapping server sends at least one message to the mobile location device over the mobile network on a randomly selected communication port to establish a secure connection with the mobile location device, as shown in block 960.

[0096] In some implementations, the processor of the mobile location device determines whether a connection with a geomapping server or a local wireless network (e.g., a mobile network) has been lost, as shown in block 970. For example, the mobile location device may send a ping message to the geomapping server after a predetermined amount of time has elapsed. In some implementations, the ping may be repeated until power to the device is disconnected or until the user actively terminates the mobile location device's connection to the geomapping server. If the mobile location device determines that a connection to the geomapping server or a connection to the local wireless network has been lost, the process 900 may return to either block 910 or 920, depending on which connection was lost. In the illustrated implementation of FIG. 9, since a connection to the geomapping server has been lost, the mobile location device begins the process 900 again in block 920 to re-establish a connection with the geomapping server. It should be understood that in some implementations, the process of establishing a connection is a manual process that must be performed by a user of the mobile location device. For example, the user must press a button on the mobile location device to start or resume the process 900. In some implementations, when the mobile location device communicates directly with the user device 140 (via USB or a low energy wireless connection), the user may have the user device 140 issue commands to the mobile location device to start or resume any portion of the process 900.

[0097] As mentioned above, process 900 is not limited to any particular system and may be employed with any device that attempts to establish a connection with a remote server.

[0098] 10A, 10B, 10C, 10D, 10E, and 10F are diagrams of some implementations using high-precision location detection in an energy dispensing (e.g., gasoline, diesel, compressed natural gas, hydrogen, electricity, etc.) and payment system. In some implementations, an energy dispensing session for a vehicle may be triggered when the vehicle decelerates below a predetermined speed threshold in a geographic location associated with an energy dispensing zone (e.g., a geolocated zone adjacent to a fuel pump or charging station). In some implementations, an energy dispensing session may be completed upon completion of a payment transaction for the dispensed energy, such as sending a receipt to a user device as a record of the purchase and payment. In some implementations, a user (e.g., user 245) places a mobile location device (e.g., mobile location device 10) in a vehicle 1000 (not shown). In some implementations, the vehicle 1000 is equipped with a mobile location device (e.g., mobile location device 10 is an embedded device). In some implementations, the mobile location device registers with a local wireless network and establishes a connection to a geo-mapping server, as described above in FIG. 9. In the scenario shown in FIG. 10A, a vehicle 1000 travels along a main street in a direction 1008 toward what visually appears to be an available energy dispensing device 1010a and an occupied energy dispensing device 1010b. In FIG. 10B and FIG. 10C, the vehicle 1000 pulls up alongside the energy dispensing device 1010a, and a mobile location device therein may continuously determine the location of the vehicle 1000 using data streams from satellites 1020a and 1020b (as well as other location data streams, such as from the VMD and / or MEMS data described above). In some implementations, slowing down the mobile location device in the vehicle 1000 until it is below a predetermined speed threshold triggers a message from the mobile location device to a geo-mapping server (not shown).In some implementations, the mobile location device transmits one or more location data points, such as 5, 10, 1, or some other suitable number of location data points, in response to the trigger, upon receipt of which the geomapping server determines from the one or more received location data points that the vehicle 1000 is within a geolocated zone 1012a associated with the energy dispensing device 1010a, e.g., pump #1. In some implementations, the mobile location device continuously transmits location data points to the geomapping server, the location data points including speed data, and the geomapping server makes a determination that the vehicle 1000 has slowed down to a speed below a predefined speed threshold, at which point the geomapping server makes the aforementioned determination that the vehicle 1000 is within the zone 1012a associated with the energy dispensing device 1010a. The geolocated zone 1012b is associated with the energy dispensing device 1010b, e.g., pump #2, which was occupied when the vehicle 1000 entered the energy dispensing station.

[0099] 10D-10F, in some implementations, upon determining that the vehicle 1000 is located within the zone 1012a associated with the energy dispensing device 1010a (pump #1), the geomapping server sends a message to the user device (e.g., user device 140) to display a message 1030 on the user device 140 to prompt the user to confirm that the user is at and desires to dispense energy from pump #1. In some implementations, when the server does not correctly determine a pump location for the user's vehicle (e.g., due to an error in location detection), the user may provide a response to correct the pump number (e.g., the user may reply to the server that the user is at pump #2). Upon such confirmation (e.g., a correct or updated pump number), in some implementations, the geomapping server may confirm to the user via a display message sent to the user device 140 successful payment authorization and pump activation, as well as a prompt to the user to begin refueling, as shown in display message 1032 on the user device 140 in FIG. 10E. In some implementations, the display message 1032 is not sent to the user device 140. In some such implementations, the trajectory of the energy dispensing device may be sufficient notification to the user to begin dispensing. In some implementations, at the end of the user's refueling operation, the server may receive notification of a payment receipt for the refueling operation from a payment processing system, which may indicate that the refueling operation is complete and that payment for the refueling operation has been made. The server may store the payment receipt and send a purchase receipt to the user device, as shown in display message 1034 on the user device 140 in FIG. 10F.

[0100] FIG. 11 illustrates several implementations of a time domain transaction diagram 1100 illustrating the operational processes and communications between certain elements of an automated energy dispensing and payment system using a high accuracy location detection system over time 1101. The diagram illustrates multiple elements, such as a user's user device 1102, an energy dispensing station system 1103, a mobile location device 1104, a geo-mapping server 1106, a database 1108, and a payment processing server 1110, and how these elements interact over time 1101 to provide a novel automated energy dispensing and payment system to a user. It should be understood that the various elements of FIG. 1100 correspond to elements discussed above. As with FIGS. 10A-10F, this diagram of FIG. 11 assumes that a mobile location device 1104 is in a vehicle (e.g., a removable transponder or an embedded system in the vehicle), that the user's user device 1102 communicates with a geo-mapping server 1106, and that the mobile location device 1104 also communicates with the geo-mapping server 1106.

[0101] Block 1112 illustrates the mobile location device 1104 transmitting the vehicle location information to the geomapping server 1106. In some implementations, the mobile location device 1104 transmits the vehicle location information to the geomapping server 1106 when the mobile location device 1104 detects a lack of vehicle movement. The lack of movement can include no movement or movement below a predetermined speed (e.g., less than 2 km / h, or some other suitable speed), triggering the mobile location device 1104 to transmit the captured location data to the geomapping server 1106 as described above. In some implementations, the mobile location device 1104 acquires a predetermined number of coordinates of the mobile location device over a predetermined amount of time. In some implementations, the mobile location device 1104 acquires and generates a single location coordinate of the vehicle and transmits the acquired location coordinate to the geomapping server 1106. In some implementations, the mobile location device 1104 acquires location coordinates every second for five seconds, or at some other suitable interval. It should be understood that the geomapping server 1106 corresponds to the geomapping server described above and may be located in the data center 120. It should also be understood that the geomapping server 1106 may represent one or more such servers, which may be in one data center or distributed across multiple different data centers. In some implementations, the mobile location device 1104 always transmits location data to the geomapping server 1106 regardless of a triggering event (e.g., detecting a speed below a predetermined threshold). The geomapping server 1106 may use this always-transmitted location data for different purposes, such as alerting the user device 1102 about potential low fuel events and providing available fueling station locations based on the user's location data transmitted to the geomapping server 1106.The location data that is constantly transmitted to the geomapping server 1106 may also be used for other purposes, such as providing targeted advertising based on the vehicle's location determined at the geomapping server 1106. In some such implementations, the mobile location device 1104 may send a special message to the geomapping server 1106 to distinguish location data captured after a trigger event (e.g., speed below a threshold) from routine and periodic location data that the mobile location device 1104 transmits to the geomapping server 1106.

[0102] In some implementations, once the geomapping server 1106 receives the vehicle location information, the geomapping server 1106 may request geographic object or geographic zone information from the database 1108 based on the vehicle location, as shown in block 1114. In some implementations, the database 1108 returns the geographic object information to the geomapping server 1106, as shown in block 1116. The geomapping server 1106 may compare the geographic object information to the vehicle location information to determine whether the vehicle is present at an energy dispensing device (e.g., a fuel pump, a recharging station, etc.), as shown in block 1118. For example, the geomapping server 1106 may compare one or more of the received coordinates to coordinates stored in the database 1108 to determine whether the vehicle location information matches a stored energy dispensing zone. In some implementations, the stored energy dispensing zones are predefined geographic coordinates that describe an area at or near the energy dispensing device (e.g., an area close enough to connect a fuel pump to add fuel to a vehicle, or an area close enough to connect a plug from an electric vehicle charger or charging station to a plug-in electric vehicle). In some implementations, the stored energy dispensing zones (e.g., graphical objects) are defined as geolocated polygons in a database. In some implementations, the geolocated polygons are stored with embedded metadata that enables automated energy dispensing sessions. For example, a geolocated polygon next to fuel pump 1 may have associated metadata that defines the fuel pump as fuel pump 1 (as opposed to fuel pump 2 or fuel pump 3), the address of the fuel station, the name of the fuel station, and / or other appropriate information that may be necessary to activate the fuel pump and automatically process payment for fuel obtained from the fuel pump.

[0103] In some implementations, the geo-mapping server 1106 employs a two-factor authorization system to confirm that an energy dispensing session should be initiated and that a particular energy dispensing device should be activated to dispense energy (e.g., gasoline, diesel, hydrogen, electricity, etc.) to refuel / charge the vehicle. In some implementations, the first factor is vehicle location detection, block 1118. In some implementations, the second factor is user confirmation that an energy dispensing session should be initiated and that a particular energy dispensing device should be activated. In some implementations, if the geo-mapping server 1106 determines that the coordinates received from the mobile location device 1104 result in a match with an energy dispensing device zone, the server may send a request to the user device 1102 to request confirmation that the user wishes to initiate an energy dispensing session (e.g., charging an electric vehicle at an electric vehicle charger, pumping fuel from a fuel pump, etc.), as shown in block 1119. In some implementations, the request to the user device 1102 may also request confirmation that the mobile location device 1104 (e.g., a vehicle) is located in a particular energy dispensing zone (e.g., in proximity to a particular energy dispensing device to obtain an associated energy source), as also shown in block 1119.

[0104] In some implementations, as shown in block 1120, the user device 1102 may send a confirmation message back to the geomapping server 1106 confirming that the mobile location device 1104 is located at a particular energy dispensing device and that the user wishes to initiate an energy dispensing session. In some implementations where the user determines that the energy dispensing device is incorrect, the user device 1102 may send a message to the geomapping server 1106 indicating a different energy dispensing device (e.g., the vehicle is located by fuel pump 3 instead of fuel pump 1). In some implementations, the confirmation request communication between the geomapping server 1106 and the user device 1102 (e.g., a mobile phone, an infotainment system, etc.) may occur through an application on the user device 1102. In some implementations, the confirmation request communication between the geomapping server 1106 and the user device 1102 may occur through short message service (SMS) between the user device 1102 and the geomapping server 1106. It should be understood that the confirmation request communication may be handled using other suitable communication exchanges. In some such implementations in which the user device 1102 sends the corrected energy dispensing device zone information (e.g., fuel pump 3) to the geo-mapping server 1106, the geo-mapping server 1106 may use the corrected energy dispensing device zone information in a subsequent action to approve and activate the energy dispensing session. It should be understood that in some implementations, the confirmation as discussed in blocks 1119 and 1120 may be skipped so that the user does not need to confirm. That is, in some implementations, after detecting that the vehicle is present at the energy dispensing device in block 1118, the geo-mapping server 1106 may move to block 1122 without the confirmation discussed in blocks 1119 and 1120. In some implementations, a different second factor authentication may be used in place of blocks 1119 and 1120 so that the user does not need to provide confirmation.

[0105] In some implementations, as shown in block 1122, the geo-mapping server 1106 may request activation of an energy dispensing device from the payment processing server 1110. For example, if the vehicle is located at a gas fuel pump, the geo-mapping server 1106 may send payment information to the payment processing server 1110 (e.g., user information, credit / debit card information, payment token information, etc.). In some implementations, the geo-mapping server 1106 may store payment information associated with the user of the vehicle. The geo-mapping server 1106 may also send a request to the payment processing server 1110 to activate a particular energy dispensing device (e.g., energy dispensing station name, energy dispensing station address, particular energy dispensing device, etc.).

[0106] In some implementations, the payment processing server 1110 may determine whether the user's payment information authorizes payment for the energy dispensing session (e.g., whether the credit card or other appropriate payment information is approved and has sufficient money to complete the transaction). Although not shown, in some implementations, the payment processor may communicate with a credit card or debit card system to determine whether a particular transaction is approved before proceeding. In some implementations, if the payment processing server determines that the payment information is appropriate, the payment processing server 1110 may send a message to authorize activation of the particular energy dispensing device, as shown in block 1124. In some implementations, if the payment processing server 1110 determines that the payment information is not valid for the energy dispensing transaction, the payment processing server 1110 may send a message to the geo-mapping server 1106 indicating that the transaction for the energy dispensing session is not authorized. In some implementations, the geo-mapping server 1106 may send a notification to the user device 1102 that the transaction for the energy dispensing session was not authorized.

[0107] In some implementations, the energy dispensing station system 1103 activates the energy dispensing device in block 1126 in response to the payment processor server sending a payment authorization for dispensing the purchase at the energy dispensing device. It should be understood that the activation of the energy dispensing device in block 1126 may be sufficient to prompt the user to begin dispensing. In some implementations, an additional prompt to the user may be provided, where the payment processing server 1110 also notifies the geo-mapping server of the authorization (not shown), and the geo-mapping server 1106 sends a message to the user device 1102 to display a prompt similar to the example display message 1032 of FIG. 10E.

[0108] In some implementations, the energy dispensing system 1103 detects the end of the energy dispensing in block 1128, such as may be indicated by returning the fuel nozzle or charging plug from the vehicle to the energy dispensing device, at which time the energy dispensing system 1103 may send purchase details to the payment processing server 1110. In some implementations, the payment processing server 1110 may process the payment based on the purchase details provided by the energy dispensing station system 1103. In some implementations, the payment processing server 1110 may send details of the purchase, payment, and confirmation to the geo-mapping server 1106. The geo-mapping server 1106 may write a transaction log of the energy dispensing session to the database 1108, including details such as user ID, mobile location device ID, user device ID, energy dispensing device ID, energy dispensing station ID, payment processor transaction number and confirmation, timestamps of one or more of the steps such as session start and end times, authorization and payment transaction times, purchase and payment details including a payment transaction receipt, etc. It should be understood that in some implementations, more or less detail may be recorded.

[0109] In some implementations, the geo-mapping server 1106, in block 1134, sends an energy dispensing session purchase and payment transaction receipt to the user device 1102, which in some implementations may then notify the user in block 1136 via one of a variety of methods, such as a push notification from a downloaded app, an SMS message, a display message, an email, etc. In some implementations, the energy dispensing device may also print a purchase and payment transaction receipt (not shown).

[0110] FIG. 12 is a flow chart of a process 1200 illustrating some implementations of a system and method for an automated energy dispensing and payment system using a high accuracy location detection system, as described in blocks 1112-1136 of FIG. 11. In some implementations, in block 1205, the mobile location device determines, using a processor, that the motion of the mobile location device has fallen below a predetermined threshold, such as the speed falling below a predetermined threshold speed, whereupon a trigger event may be generated, and a vehicle location message may be sent from the mobile location device to a geo-mapping server, as described above for block 1112 of FIG. 11, some implementations of a process for obtaining location data points were described in connection with FIGs. 7 and 8. In some implementations, in block 1210, the geo-mapping server determines that the vehicle is located at a particular energy dispensing device using the location data and the geographic object data, as described above for blocks 1114 and 1116. At block 1215, some implementations effect two-factor authentication in addition to the received location data, and the geo-mapping server prompts the user via a user device (e.g., smartphone, infotainment system, etc.) to confirm that the vehicle is located at the determined particular energy dispensing device, as described above at blocks 1119 and 1120, and that the user wishes to initiate refueling. In some implementations, at block 1220, the geo-mapping server requests activation of the particular energy dispensing device from a payment processing system, as described above at block 1122, and the payment processor, in some implementations, may pre-authorize a payment for a particular amount, as described above at block 1124, and upon successful authorization, activate the energy dispensing device (as in block 1126 above). In some implementations, at block 1225, the geo-mapping server may verify whether the payment authorization was successful and thus activation of the energy dispensing device was authorized.If not, in some implementations, process 1200 may proceed to block 1230 and send a message to the user device indicating that authorization was denied. If activation is confirmed / authorized in block 1225, the process proceeds to block 1235 and the energy dispensing device is activated as described above in block 1126. In some implementations, in block 1240, the energy dispensing is determined to be complete as described above in block 1128, whereupon, in some implementations, the purchase details are sent to a payment processor for completion of the payment process. In some implementations, as shown in block 1245, the payment processor may send a receipt to a geo-mapping server as described above in block 1130. In some implementations, as shown in block 1250, the geo-mapping receives and stores / records the payment receipt / transaction details as described above in block 1132. Process 1200 then proceeds to block 1255, where the geo-mapping server sends a purchase and payment transaction receipt to the user device (e.g., a smartphone or infotainment system), as described above in block 1136.

[0111] 10A-12 disclosed a novel system and method for an automated energy dispensing and payment system using a high-precision location detection system. FIG. 13A-15 disclose a novel system and method for an automated parking and payment system using a high-precision location detection system. FIG. 13A, FIG. 13B, FIG. 13C, FIG. 13D, FIG. 13E, and FIG. 13F are diagrams of some implementations using high-precision location detection in a parking and payment system. A parking session of a vehicle is initiated at a geographic location associated with a legal parking zone, and the parking session is then stopped when the vehicle leaves the parking zone. A user places a mobile location device (e.g., mobile location device 10) in a vehicle 1300 (not shown). The mobile location device registers with a local wireless network and establishes a connection to a geo-mapping server, as described above in FIG. 9. As described above, the mobile location device can alternatively be an embedded system with the vehicle 1300. Using a mobile location device, a user can drive through a city that has legal parking zones (see, e.g., FIG. 13A, available parking stall 1310). The vehicle 1300 drives along K Street in direction 1308 to what visually appears to be an available parking stall 1310. In FIG. 13B, the vehicle 1300 parks in the available parking stall 1310. In some implementations, the mobile location device automatically determines that the vehicle may be parked or the user presses a button on the mobile location device to notify the mobile location device to check for parking zones. In some implementations, the mobile location device in the vehicle 1300 uses data streams from satellites 1320a and 1320b (as well as other location data streams described above) to determine the location of the vehicle 1300.

[0112] After communicating with a geomapping server (not shown), the geomapping server determines that the vehicle 1300 has arrived at a legal parking zone (FIG. 13C). In some implementations, after a pre-set amount of time or after a manual action by the user (activating a button on the mobile location device), the mobile location device sends a request to the geomapping server to initiate a parking session. If the geomapping server determines that the parking session has been successfully initiated, the geomapping server, in some implementations, alerts the mobile location device. As shown in FIG. 13D, in some implementations, the mobile location device changes an LED on the mobile location device (turning it green or blinking the LED) to notify the user that the parking session has begun. In some implementations, the geomapping server transmits information regarding the expiration time, fee, and time limit back to the mobile location device (when the mobile location device includes a display screen) and to a user device associated with the user, via other suitable methods of communicating with the user, or some combination of the above. In some implementations in which the mobile location device includes a display, the mobile location device may display the expiration time; for example, assuming the zone has a two-hour limit and it is currently 11:23AM, the display may read "Expired at 1:23PM" (not shown). At some point between 11:23AM and 1:23PM, the user returns to the vehicle 1300 and begins driving away from the parking stall in a direction 1312 (FIG. 13E). In some implementations, the mobile location device detects movement (e.g., movement at greater than 5 miles per hour or some other suitable speed using a GNSS module), and the mobile location device sends a request to the geomapping server to terminate the parking session. In one such implementation, the geomapping server stops the parking session, processes payment for the parking session (when necessary), and sends a payment receipt 1330 to the user (FIG. 13F).

[0113] FIG. 14 illustrates several implementations of a time domain transaction diagram 1400 illustrating the operational processes and communications between certain elements of a parking and payment system using a high accuracy location detection system over time 1401. The diagram illustrates multiple elements, such as a user's user device 1402, a mobile location device 1404, a server 1406 (e.g., a geo-mapping server), a database 1408 that stores geographic objects, among others, and a payment processing server 1410, and how these elements interact over time 1401 to provide a novel parking and payment system to a user. It should be understood that the various elements of diagram 1400 correspond to elements discussed above. As with FIGS. 13A-13F, this diagram of FIG. 14 assumes that the mobile location device 1404 is in a vehicle, that the user's user device 1402 is communicating with the server 1406, and that the mobile location device 1404 has registered with the local wireless network and established a connection with the server 1406 as described above in FIG. 9.

[0114] Block 1412 indicates that the mobile location device 1404 detects a lack of motion and sends a message to the server 1406. In some implementations, the message to the server 1406 may include location information / data. In some implementations, the message may include a request from the server 1406 for an evaluation of the parking event. In some implementations, the request may be in the form of a special message (e.g., a check message). The lack of motion may include motion below a predetermined speed (e.g., below 2 km / h or 5 km / h or some other suitable predetermined speed threshold), triggering the mobile location device 1404 to obtain location data as discussed in FIG. 7 and FIG. 8. In some implementations, the mobile location device 1404 obtains a predetermined number of coordinates of the mobile location device over a predetermined amount of time. In some implementations, the mobile location device 1404 obtains and generates one coordinate of the mobile location device 1404 every two seconds for ten seconds as described above according to FIG. 7 and FIG. 8. The mobile location device 1404 then transmits these five obtained coordinates to the server 1406 (as part of an evaluation request). In some implementations, these five obtained coordinates are transmitted in a check message to alert the server 1406 to confirm whether a particular transaction should be performed (e.g., a parking session, a refueling session, etc.). It should be understood that the server 1406 corresponds to the geo-mapping server described above and may be located in the data center 120. It should also be understood that the server 1406 may represent one or more such servers, which may be in one data center or distributed across multiple different data centers. In some implementations, the mobile location device 1404 always transmits location data to the server 1406 regardless of a triggering event (e.g., detecting a speed below a predetermined threshold or no motion detected).The server 1406 may use this constantly transmitted location data for different purposes, such as to alert the user device 1402 about potential low fuel events, provide available fueling station locations, and the like based on the user's location data transmitted to the server 1406. The constantly transmitted location data to the server 1406 may also be used for other purposes, such as to provide targeted advertisements based on the vehicle's location determined at the server 1406. In some such implementations, the mobile location device 1404 may send a special message to the server 1406 to distinguish location data captured after a trigger event (e.g., speed below a threshold) from routine and periodic location data that the mobile location device 1404 transmits to the server 1406.

[0115] In some implementations, the mobile location device 1404 may be unable to acquire coordinate data due to a number of factors. In some such cases, the mobile location device 1404 may notify the user (via an LED warning, display, via a message to the user device 1402) that the parking session cannot be initiated (this process is not shown).

[0116] Returning to FIG. 14, the server 1406 receives a request 1414 to evaluate a parking event. The server 1406 may compare one or more of the received coordinates to coordinates stored in the database 1408 to determine whether any of the coordinates match a stored legal parking zone (e.g., a legal parking zone that may be stored as a geographic object or a geographic zone as discussed in connection with the energy dispensing use case) (see blocks 1416 and 1418). In some implementations, all of the coordinates must match, within a certain range, the coordinates of the legal parking zone to be declared a match. In some implementations, some predetermined percentage of the coordinates received from the mobile location device 1404 must match coordinates associated with a legal parking zone stored in the database 1408 before the server 1406 determines that the mobile location device (or vehicle) is within a legal parking zone. In some implementations, at least one of the received coordinates should match the coordinates of the legal parking zone to be declared a match. If the server 1406 determines that the coordinates received from the mobile location device 1404 result in a match with a legal parking zone, the server returns a message 1420 to the mobile location device 1404, confirming that the mobile location device is in a legal parking zone. In some implementations, the mobile location device 1404 does not provide the user with information regarding the injection. In some such implementations, the server 1406 may send the message 1420 to the user device 1402. On the other hand, if the server 1406 determines that the coordinates received from the mobile location device 1404 do not result in a match with a legal parking zone, the server returns a message (not shown) to the mobile location device 1404 requesting a retry of the process beginning at 1412, indicating that parking is not permitted or that the user should initiate a manual parking fee payment process.If the mobile location device 1404 performs too many attempts to verify a parking event within a predetermined period of time and results in no match with a legal parking zone, the mobile location device 1404 or server 1406 may suspend further retries of the process for a predetermined amount of time. Some implementations of blocks 1412-1420 are discussed in more detail in FIG. 15 below.

[0117] In some implementations, once the mobile location device 1404 receives a confirmation message 1420 that the mobile location device is within a legal parking zone, the mobile location device 1404 may request to initiate a parking session, as shown in block 1422. The mobile location device 1404 may make the request to the server 1406 automatically. In some implementations, the mobile location device 1404 makes the request to the server 1406 after a user presses one or more buttons on the mobile location device 1404 to send a request. In some implementations, a user may initiate a request to initiate a parking session from a user device 1402 (not shown) instead of or in conjunction with using the mobile location device 1404. In some implementations, the mobile location device 1404 waits a predetermined amount of time before sending an automatic request to initiate a parking session to the server 1406. For example, the mobile location device 1404 may wait one minute or some other suitable amount of time. The mobile location device 1404 may allow a user to press a button on the mobile location device to prevent the mobile location device from sending a request to initiate a parking session.

[0118] In some implementations, when a parking session is initiated, the mobile location device may stop or limit power to one or more modules in the mobile location device. For example, during a parking session, the mobile location device 1404 does not need to receive GNSS data. Thus, at the start of a parking session, the mobile location device 1404 may stop or limit power to the GNSS module. It should be appreciated that the mobile location device 1404 may evaluate each module to determine whether the module is needed for a particular situation given the situation. If the module is not needed, the mobile location device 1404 stops or limits power to such module. It should be appreciated that in some implementations, the use of situational power limitations in the mobile location device may allow the battery life of the mobile location device to be extended by two or three times over its runtime compared to a situation in which all of the modules of the mobile location device remain operational the entire time, creating a much more efficient device.

[0119] At block 1424, the server receives the request and initiates a parking session associated with the mobile location device 1404 within the legal parking zone. The server may send a notification regarding the parking session to the mobile location device 1404 and to the user's user device 1402. The notification may include attributes associated with the legal parking zone, such as the cost per unit time to park, the start of the parking session, the maximum time parking is allowed within the legal parking zone, as shown in block 1426. In some implementations, the parking session may be prepaid. In another implementation, payment is not made before the user ends the parking session, until the mobile location device leaves the legal parking zone, until the maximum parking time is reached, etc. In some implementations, the parking session is a pay-as-you-go model such that the user pays only for the time the mobile location device 1404 (and vehicle) is within the legal parking zone. It should be appreciated that such a system alleviates the need to guess how much parking time is needed, alleviates the need to prepay for more parking time than is needed, and reduces the time a user spends attending to pay (running back to put money in the meter or adding more time through a cell phone app). In block 1428, the server also records the parking session and the start of the parking session associated with the mobile location device 1404.

[0120] In some implementations, when the mobile location device 1404 detects a driving event (e.g., when a MEMS module in the mobile location device 1404 detects movement greater than a predetermined amount or a GNSS module in the mobile location device 1404 detects a speed greater than a predetermined amount), the mobile location device 1404 determines that the parking session should be terminated as shown in block 1430. Other events may include a user pressing a button on the mobile location device 1404 to terminate the parking session, or a user pressing a button of an application on the user device 1402 to terminate the parking session. In block 1432, the mobile location device 1404 sends a request to the server 1406 to terminate the parking session. In some implementations (not shown), the server 1406 initiates the parking session termination due to factors such as reaching a maximum legal parking time, expiring a prepaid parking session, or receiving a separate parking session termination request from the user device 1402. In some implementations, the server 1406 may also initiate a parking session termination when the mobile location device 1404 loses power during the parking session or for some other suitable reason where the server 1406 is configured to terminate the parking session prior to receiving a termination request from the mobile location device 1404. In some implementations, if a user attempts to manually stop the parking session through the user device 1402 and the mobile location device 1404 does not respond, the server 1406 may terminate the parking session without further communication with the mobile location device 1404 and trigger a payment process by the payment processing server 1410 because the mobile location device 1404 is unreachable (e.g., the mobile location device 1404 is turned off, the battery is dead, there are problems with cellular network coverage, etc.).

[0121] Returning to block 1434, the server 1406 receives a parking session termination request from the mobile location device 1404 and terminates the parking session. In some implementations, the server 1406 stores a log of all or part of the parking session, including the termination time, in a database 1408. If the legal parking zone required payment (and the user did not prepay), the server 1406 calculates the required payment based on the time and the parking zone fee. The server 1406 sends the parking session bill to the payment processing server 1410, as shown in block 1436. The payment processing server 1410 performs the billing for the parking session of the mobile location device 1404 (e.g., bill the user's credit card or debit the user's bank card). The payment processing server 1410 then sends a payment confirmation back to the server 1406, as shown in block 1438. As mentioned above, in some implementations, parking in some legal parking zones may not require payment, and therefore a transaction with the payment processing server 1410 may not be required.

[0122] In some implementations, the server 1406 may send a message to the mobile location device 1404 and the user device 1402 confirming the end of the parking session, as shown in block 1440. In some implementations, the server 1406 may also send log information regarding the parking session and a receipt for any charges made for the parking session, as shown in block 1440.

[0123] In some implementations, the mobile location device 1404 receives the parking session termination message in block 1442 and alerts the user in any suitable manner. In some implementations, the mobile location device 1404 alerts the user by changing an LED (e.g., turning the LED red or blinking the LED in a particular pattern). Similarly, the user's user device 1402 alerts the user in any suitable manner after receiving the parking session termination message in block 1444. One such display is shown in FIG. The user device 1402 may also display payment receipt information in an application.

[0124] 14 may be repeated any number of times as the mobile location device 1404 detects a possible parking event. It should be appreciated that the above-described system, in some implementations, allows a user to park, know that the user is within a legal parking zone, and automatically pays the parking fee without the user taking any additional affirmative action (although it should be appreciated that in some implementations the user may be required to affirmatively confirm a legal parking zone for the parking session and accept or approve a credit card, direct debit, or other charge for the parking session).

[0125] In some implementations, when a user has prepaid for a parking session and is legally able to park for additional time, the system may automatically purchase additional time for parking lot use if the vehicle and mobile location device have not moved upon expiration of the parking session. Alternatively, a geo-mapping server (e.g., server 1406) may automatically alert the user to purchase additional time to extend the parking session or start a new parking session. It should be understood that in some implementations, the functionality of the mobile location device 1404 that allows the user to interface with the mobile location device 1404 may be included in the user device 1402 (e.g., a mobile application or a vehicle infotainment application) to the extent that the user does not need to interact with the mobile location device 1404 to start and / or end a parking session.

[0126] FIG. 15 is a flow chart of a process 1500 illustrating some implementations of a system and method for automatically detecting a possible parking event, as described in blocks 1412-1444 of FIG. 14. In block 1505, the mobile location device, using a processor, determines that the motion of the mobile location device has stopped or is below a predetermined threshold speed for a predetermined amount of time. In block 1510, the mobile location device collects, analyzes, and calculates a predetermined number of coordinate data points for the mobile location device over the predetermined amount of time. Some implementations of the process of block 1510 were described in connection with FIG. 7 and FIG. 8. In block 1515, the mobile location device transmits the calculated predetermined number of coordinate data points to a geomapping server over a virtual private network or other suitable communication channel. The geomapping server receives the calculated predetermined number of coordinate data points in block 1520.

[0127] In block 1525, the geomapping server analyzes the calculated predetermined number of coordinate data points to determine whether a lack of movement of the mobile location device triggers a parking event in a legal parking zone. As shown in FIG. 14, the geomapping server may compare some or all of the predetermined number of coordinate data points against coordinates stored in association with a legal parking zone. In some implementations, if the geomapping server determines that the predetermined number of coordinate data points are within two meters (or some other suitable distance) of a legal parking zone, the geomapping server knows with a high probability that the mobile location device is within a legal parking zone. In some implementations, the geomapping server compares the calculated predetermined number of coordinate data points (including the direction the mobile location device was traveling in some implementations) with stored road alignment data, such as coordinates of the road's centerline and coordinates of the road's curb, as part of the analysis. The high accuracy of the calculated predetermined number of coordinate data points allows the server to determine whether the mobile location device (and vehicle) is close to the centerline of the road or in view of the curb (which may indicate that the vehicle is stuck in traffic on a narrow road, rather than trying to park on the narrow road). The road alignment data also allows the geomapping server to ignore bad coordinate data, such as if the calculated coordinate data indicates that the vehicle is located on a sidewalk or inside a building (which may occur due to multipath signal distortion). If there is a good match and other factors rule out issues such as traffic on a narrow road, the geomapping server verifies at block 1530 that a parking event has occurred and that the parking event is within a legal parking zone. The mobile location device and geomapping server may automatically initiate the parking session at block 1550 discussed in FIG. 14, or may allow the user of the mobile location device to manually initiate the parking session using the mobile location device (e.g., by pressing a button) or a software application on the user's user device (which executes the parking session initiation).Then the process 1500 ends.

[0128] On the other hand, if there is no suitable coordinate match, the geomapping server may send a message to the mobile location device indicating that the parking event did not occur or that the parking event is not within a legal parking zone at block 1530. In some implementations, the coordinates provided by the mobile location device may have been corrupted in a variety of different ways as described above. In some implementations, the process 1500 includes enabling the mobile location device to obtain and calculate new coordinate data points. In some implementations, the mobile location device may attempt to confirm the parking event a predetermined amount of times, such as three times. However, any suitable number of times may be used. In this manner, the mobile location device is given one or more opportunities to obtain a new set of location data to mitigate the cause of the previously unmatched coordinate data. In one such implementation, the geomapping server may increment a parking event detection counter at block 1535. If the incremented parking event detection counter is below a predetermined number at block 1540, the process returns to block 1510 for the mobile location device to obtain and calculate new coordinates for transmission to the geomapping server. If the incremented parking event detection counter is equal to a predetermined number at block 1540, process 1500 proceeds to block 1545. The geo-mapping server sends a message to the mobile location device, the user's user device, or both informing the user that parking is not permitted at the current location or that the user should initiate a manual parking payment process (e.g., by putting money in a parking meter or paying at a parking kiosk), and process 1500 ends at block 1555. In some implementations, process 1500 may be restarted manually or automatically after a predetermined amount of time for the same zone.

[0129] 16A, 16B, and 16C are diagrams illustrating example implementations of screenshots of a mobile application corresponding to various states of the parking system (currently active session, no active session, and locating the vehicle). In some implementations, a user may choose to install the parking application on their user device 140, such as a smartphone, a smartwatch, or an infotainment system, or other suitable portable or mobile device capable of wireless data communication and compatible with the parking application. In some implementations, the mobile application communicates parking-related events received from the geo-mapping server to the user and allows the user to remotely manage and control the parking account maintained with the geo-mapping server. In some implementations, the mobile application may obtain alerts regarding the mobile location device, such as battery levels, reminders to charge the battery of the mobile location device, operational issues with the mobile location device, etc.

[0130] FIG. 16A illustrates some implementations of a mobile app screen 1600 displayed on a user device when the mobile location device in the user's vehicle is in an active parking session. Reference numeral 16A-1 indicates the time remaining until the expiration of the maximum time allowed to park in the zone. Reference numeral 16A-2 indicates the cost of parking incurred by the user from the beginning of the parking session in some example implementations. If parking is free and the vehicle is parked in a zone known to the system, in some implementations reference numeral 16A-1 may display the time until the end of the longest stay in a given parking stall, and reference numeral 16A-2 may reflect the $0 cost incurred. For example, some US cities have street parking zones where parking is only allowed for a given period and a maximum time limit of, for example, 2 hours. The mobile application can be used to set the necessary reminders so that the user does not have to remember to return to their vehicle on time. In some implementations, the reminders are automatically created for the user when the mobile application (user device) communicates with the geomapping server. The time and duration restrictions for parking in that zone may be stored in a database associated with the system (eg, database 1408 of FIG. 14).

[0131] Reference numeral 16A-3 displays a touch-sensitive "Start" button with the same functionality as a button on the mobile location device that can be used to manually start a parking session in some exemplary implementations. Reference numeral 16A-4 displays a touch-sensitive "Stop / Cancel" button with the same functionality as a button on the mobile location device that can be used to manually stop a parking session in some implementations. Thus, the mobile application provides remote interaction with the system without using the physical interface of the mobile location device. However, as mentioned above, in some implementations, the user device (and mobile application) may communicate directly with the mobile location device, control the mobile location device through this communication channel, and can also access the parking and payment system through the mobile location device.

[0132] 16B shows another implementation of a screen 1610 displayed by the mobile application when the mobile location device and vehicle are not parked in any legal parking zone or any legal parking zone that requires access to the parking and payment system. Thus, in some implementations, reference numeral 16A-1 does not display any time remaining and reference numeral 16A-2 displays "OFF" since the cost increase meter is not moving.

[0133] 16C shows a built-in map interface screen 1620 in some implementations that can be used by a user of the parking and payment system to locate his or her parked vehicle and quickly get there (if necessary) following the provided routing instructions 16A-5. The map interface can be used in other implementations to convey information to the user about legal parking zones and guide the user to the zone most relevant to the destination. In a further implementation, the information included on the map interface includes time restrictions and fees for legal parking zones.

[0134] In some implementations, the map interface retrieves real-time (or near real-time) stall availability information from the parking and payment system and highlights the location of vacant parking spaces to help the user quickly locate a parking stall. In some implementations, the screen 1620 may allow the user to select a button to get the closest parking lot, stall rates, and space availability. In some implementations, when many mobile location devices are in use, the geo-mapping server tracks which legal parking zones are occupied by the mobile location devices and which legal parking zones are not occupied by the mobile location devices.

[0135] In some implementations, the geomapping server tracks and stores, in real-time or near real-time, currently occupied spaces that have been vacated by vehicles using mobile location devices (e.g., mobile location devices that have recently ended a parking session and are moving). When a user is searching for a parking space (also referred to herein as a legal parking space) in a legal parking zone near the user's current location, the geomapping server, in some implementations, may transmit to such user recently vacated parking spaces known to the geomapping server. The geomapping server may transmit such information to the user's user device (so that the user may obtain a map and directions to the recently vacated space). In some implementations, the determination of recently vacated parking spaces may be based on a predetermined time period. For example, recently vacated legal parking spaces in a legal parking zone may include legal parking spaces that have been vacated within the last 2-4 minutes. This predetermined number may vary depending on the jurisdiction (to adjust for highly dense urban areas where legal parking spaces are in high demand and even 60 seconds may cause information to become stale and inaccurate), time of day, or other suitable factors. It should therefore be appreciated that one advantage of a mobile location device communicating with a geomapping server to terminate a parking session is that the geomapping server has real-time or near real-time information regarding the availability of legal parking spaces within a legal parking zone. As the number of mobile location devices increases within a given geographic area, the amount of available real-time or near real-time parking data likewise increases.

[0136] 17A and 17B show some implementations in which a mobile location device 1710 (corresponding to the mobile location device 10) is integrated (or embedded) into the on-board electronics system of a vehicle 1700 (e.g., vehicle 20). A vehicle computer 1730 can be connected to the mobile location device 1710 via an existing bus link, such as a controller area network (CAN) interface (1750). In some implementations, the vehicle computer 1730 can control a vehicle display 1740, which in some implementations can be a display of an interactive embedded infotainment system, and can communicate user device messages and receive and transmit user responses, such as energy dispensing, parking, toll collection, curbside pickup, etc., through the vehicle display 1740 and, in some implementations, a vehicle audio system (not shown). A vehicle battery 1720 is used as a power source in some implementations. FIG. 17B shows some implementations in which the integration of the vehicle computer 1730 is performed using a standard OBD II (on-board diagnostics) port 1760 in the vehicle 1700. The exact integration scheme for such integration may depend on the vehicle manufacturer and the specific features of the vehicle. The integration shown in FIG. 17B is only one example, and other forms of integration may be possible or necessary. In some implementations, a CAN bus high / low may be used for the communication link, signal and chassis ground may be used together for grounding, and a +12V power supply may be used to power the mobile location device 1770 (which may correspond to the mobile location device 10).

[0137] In some implementations, the mobile location device is not fully integrated into the vehicle's onboard electronics system. For example, an integrated communication system may be present in certain vehicle models and include a wireless communication interface that may be adapted to establish a link between the mobile location device and a geomapping server. In such cases, only certain components of the mobile location device, such as a high-precision geolocation positioning system (whether implemented in hardware or software) and certain algorithms, need to be additionally integrated into the vehicle system.

[0138] In some implementations, the mobile location device can be configured with an alphanumeric display that can provide useful information to the user and also assist parking wardens in enforcing parking rules. In some implementations, the mobile location device has an electronic display to communicate messages to the user and parking wardens, such as the time of expiration of the current parking session, the battery level of the mobile location device, or a reminder to charge the mobile location device if the battery level is low. The user can choose to pay attention to such messages on the display screen and follow them to ensure that the system is operating properly. If the mobile location device is placed on the windshield of the user's vehicle and easily visible from outside the vehicle, the parking wardens can use the information from the display to establish whether the vehicle is legally parked and whether a payment is processed for the vehicle to remain within the parking zone. For example, a message to parking enforcement can read "Expires at 1:23 PM" and if the current time is, for example, 1:11 PM, this message is telling the enforcement officer that there is still time for the vehicle to stay legally in the parking space.

[0139] In some implementations, an LED light on the mobile location device can be used in lieu of a display screen or as an additional indicator of an active parking session or other messages, such as error messages, that are communicated to users and parking attendants. For example, the mobile location device can illuminate the LED light with a solid green light (not flashing) when a parking session is active. In another example, the mobile location device can flash or blink the LED light if an error occurs or if a parking session has not started.

[0140] In another implementation, the mobile location device may be equipped with a speaker to facilitate communication with the user by providing additional messages in audio format. For example, when the user arrives at a legal parking zone and the mobile location device does not move for a pre-set amount of time (e.g., 30 seconds, 1 minute, some other suitable amount of time), the mobile location device may attempt to register for the parking event and announce by the speaker information obtained from the geo-mapping server, such as the time limit and fee of the legal parking zone. Such a message might say, "You have successfully parked your vehicle. You may stay here for 2 hours until 1:23 PM, and you will pay $2 per hour."

[0141] In some implementations, the mobile location device can be configured to communicate with a parking enforcement device or an energy dispensing device. For example, in implementations where the mobile location device includes a low energy wireless communication system, the mobile location device can receive a request for information from a parking enforcement device that is also configured with a compatible low energy wireless communication system. The mobile location device can provide information regarding the mobile location device's active parking session. Alternatively, when the mobile location device does not have an active parking session, the mobile location device can provide its identification information to the parking enforcement device so that the parking enforcement officer can generate a ticket based on the mobile location device's account information. In this manner, the parking enforcement officer can quickly walk or drive by the vehicle with the mobile location device and automatically know which vehicles are legally parked. In some implementations, the parking enforcement officer can send an invoice for the parking violation to a geo-mapping server for processing. In this manner, the geo-mapping server can alert the user to the parking violation and provide the user with a ticket. In some implementations, the geo-mapping server allows the user to pay for the ticket through a parking and payment system. The user can authorize the payment using a user device application or by pressing a button on the mobile location device to authorize the payment. In some implementations, when a parking attendant generates a ticket associated with one mobile location device and sends that information to a geomapping server, the geomapping server may send alerts to users of other nearby (e.g., within a three block radius, or other suitable radius) mobile location devices that are not within a legal parking zone (or have inactive parking sessions) to move their vehicles into a legal parking zone or activate a parking session.In an energy dispensing scenario, the mobile location device can communicate with the energy dispensing device using a compatible low energy wireless communication system to request authorization and activation of the energy dispensing device. For example, the mobile location device can communicate with the fuel pump to provide user information, such as credit card information, to be used to authorize the refueling session to activate the fuel pump to dispense fuel. The interaction between the fuel pump and the payment processor can replace or be an alternative to a geo-mapping server requesting authorization of the fuel pump, as shown in FIG. 11 at blocks 1122 and 1124.

[0142] In some implementations, a user with a mobile location device may be provided with a unique barcode, QR code, or other machine-readable code associated with the mobile location device or the user's account with the geomapping server. The machine-readable code may be placed in a visible area of ​​the user's vehicle while the mobile location device remains hidden within the vehicle. When a parking attendant scans the machine-readable code, the parking enforcement device may send a request for information associated with the machine-readable code to the geomapping server. If the mobile location device initiates a parking session in a legal parking zone, the query geomapping server responds to the parking enforcement device with a message that the vehicle is parked legally. The geomapping server may provide other useful information such as when the parking session expires and whether additional parking time can be purchased. The geomapping server may also have other information about the vehicle (e.g., the number of tickets associated with the vehicle, whether an outstanding law enforcement flag is associated with the vehicle).

[0143] In some implementations, the geomapping server collects crowd-sourced data from users to update the database of legal parking zones. In some implementations, a user may select a function of the user's user device that sends a request to the geomapping server to obtain coordinates of the user's mobile location device as being within a new legal parking zone. The geomapping server may send a request for the mobile location device to calculate its current coordinates and send such coordinates back to the geomapping server for consideration as a potential new legal parking zone. In some implementations, the geomapping server may send a request to a local or state government server to confirm that such coordinates are associated with a new legal parking zone. If confirmation is received from the government server, the geomapping server may update its database to reflect that such coordinates are a new legal parking zone for future parking sessions. In some implementations, a button on the mobile location device may be associated with notifying the geomapping server that the current location of the mobile location device is associated with a new legal parking zone.

[0144] In some implementations, if the geomapping server receives multiple requests from different users for a particular set of calculated coordinate data to be associated with a new legal parking zone, the geomapping server may automatically add such calculated coordinate data to its database as a new legal parking zone for future parking sessions. The minimum number of requests may be five or more requests, provided that any suitable number of requests may be used as a threshold for adding the calculated coordinate data to the geomapping server's database of legal parking zones. In some implementations, the user may provide additional information about the new legal parking zone to the geomapping server, such as the maximum number of parking times in the new legal parking zone, the cost per hour, etc. In some implementations, this additional information is added to the database when a predetermined number of users have provided the same information about the new legal parking zone. In some implementations, the user may provide such information through an application on the user's user device.

[0145] The implementations described herein may be implemented in hardware, firmware, software, or any combination thereof. The implementations disclosed herein may also be implemented as instructions stored on a machine-readable medium that can be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include read-only memory (ROM); random access memory (RAM); hardware memory of handheld computers, PDAs, smartphones, and other portable devices; magnetic disk storage media; optical storage media; USB drives and other flash memory devices; Internet cloud storage, and the like. Furthermore, firmware, software, routines, instructions may be described herein as performing certain operations. However, it should be understood that such description is merely for convenience and that such operations actually result from a computing device, processor, controller, or other device executing the firmware, software, routines, instructions, and the like.

[0146] Although the method / process operations (e.g., blocks) may be described in a particular order, it should be understood that other housekeeping operations can be performed between operations, or operations can be coordinated to occur at different times, or can be distributed within the system to occur at various intervals associated with the processing, so long as the processing of the overlay operation is performed in a desired manner.

[0147] The present disclosure is not limited with respect to the specific implementations described in the present disclosure, which are intended as examples of various aspects. Moreover, the various disclosed implementations can be used interchangeably with one another unless otherwise specified. As will be apparent to those skilled in the art, many modifications and variations can be made without departing from the spirit and scope thereof. In addition to those recited herein, functionally equivalent methods and apparatuses within the scope of the present disclosure will be apparent to those skilled in the art from the above description. Such modifications and variations are intended to be included within the scope of the appended claims. The present disclosure should be limited only by the terms of the appended claims, and the full scope of equivalents to which such claims are entitled. It should also be understood that the terminology used herein is for the purpose of describing specific implementations, and is not intended to be limiting.

[0148] With respect to the use of virtually any plural and / or singular term herein, those of skill in the art can convert from plural to singular and / or from singular to plural as appropriate to the context and / or application. The various singular / plural permutations may be expressly set forth herein for clarity.

[0149] It will be understood by those skilled in the art that, in general, the terms used herein, and particularly in the appended claims (e.g., the body of the appended claims), are generally intended as "open" terms (e.g., the term "including" should be interpreted as "including but not limited to," the term "having" should be interpreted as "having at least," the term "includes" should be interpreted as "including but not limited to," etc.). It will be further understood by those skilled in the art that, where a particular number of introduced claim recitations are intended, such intent will be explicitly set forth in the claim, and in the absence of such recitation, no such intent exists. For example, to aid in understanding, the following appended claims may include the use of the introductory phrases "at least one" and "one or more" to introduce the claim recitations. However, the use of such phrases should not be interpreted as implying that the introduction of a claim recitation with the indefinite article "a" or "an" limits any particular claim that includes such an introduced claim recitation to implementations that include only one such recitation, even when the same claim includes the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should be interpreted to mean "at least one" or "one or more"). The same can be said about the use of definite articles used to introduce claim recitations. In addition, even if a specific number of introduced claim recitations is explicitly recited, one of ordinary skill in the art will recognize that such recitation should be interpreted to mean at least the recited number (e.g., the bare recitation "two recitations" without any other modifier means at least two recitations, or two or more recitations).Furthermore, in instances where a convention similar to "at least one of A, B, and C, etc." is used, such structure is generally intended to be understood by one of ordinary skill in the art (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and B together). In instances where a convention similar to "at least one of A, B, or C, etc." is used, such structure is generally intended to be understood by one of ordinary skill in the art (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and B together). It will be further understood by those of skill in the art that virtually any disjunctive word and / or phrase expressing two or more alternative terms, regardless of where in the specification, claims, or drawings, is understood to contemplate the possibility of including one of the terms, either one of the terms, or both terms. For example, the phrase "A or B" is understood to include the possibilities of "A" or "B" or "A and B." Additionally, when features or aspects of the disclosure are described in terms of a Markush group, those of skill in the art will recognize that the disclosure is hereby described in terms of any individual member or subgroup of members of the Markush group.

[0150] Several implementations have been described. Various modifications may be made without departing from the spirit and scope of the present disclosure. For example, the various methods / processes shown above may be used with operations or steps rearranged, added, or omitted. Accordingly, other implementations are within the scope of the following claims.

Claims

1. 1. A location device, comprising: A processor; When executed by the processor, the processor is receiving Global Navigation Satellite System (GNSS) data and vehicle motion data, said GNSS data and said vehicle motion data being associated with a vehicle; calculating, in an estimation filter operating in a first mode, a location of the vehicle based on the GNSS data and the vehicle motion data; determining that the speed of the vehicle is below a threshold speed; modifying the estimation filter to operate in a second mode based on the speed being below the threshold speed; calculating a position location of the vehicle in the estimation filter operating in the second mode, and at least some of the GNSS data and the vehicle motion data are modified so that the estimation filter determines the position location of the vehicle; transmitting the position location of the vehicle to a geo-mapping server that enables vehicle-based transactions; a memory device storing a plurality of instructions configured to: A location device comprising:

2. The location device of claim 1 , wherein changes in at least some of the GNSS data and the vehicle motion data cause changes in the vehicle speed data.

3. The location device of claim 1 , wherein altering at least some of the GNSS data and the vehicle motion data alters vehicle yaw rate data.

4. The location device of claim 1 , wherein the processor is further configured to calculate and capture a plurality of location points when the estimation filter is operating in the second mode.

5. the velocity of the vehicle is a first velocity value received in the GNSS data, and the processor: receiving one or more signal strength indicators in the GNSS data; determining not to use the first speed value from the one or more signal strength indicators; calculating a second velocity value based at least in part on the vehicle motion data; The location device of claim 1 further configured to:

6. The location device of claim 5 , wherein said second velocity value is calculated at least in part using vehicle acceleration data from said vehicle motion data.

7. The location device of claim 1 , wherein the estimation filter is a Kalman filter, the Kalman filter including multiple modes.

8. The location device of claim 1 , wherein the vehicle-based transaction is triggered based on the position location being at a predetermined location, and the vehicle-based transaction is an energy dispensing session at an energy dispensing device.

9. The location device of claim 8, wherein the processor is further configured to enable the energy dispensing session at the energy dispensing device using two-factor authentication, a first authentication factor based at least in part on the transmitted position location and a second authentication factor based at least in part on a communication from a user device.

10. The location device of claim 9 , wherein the communication from a user device identifies the energy dispensing device.

11. The location device of claim 9 , wherein the energy dispensing device is a first energy dispensing device and the communication from a user device identifies a second energy dispensing device.

12. The location device of claim 1 , wherein the energy dispensing device is a fuel pump.

13. The location device of claim 1 , wherein the energy dispensing device is an electric vehicle charger.

14. The location device of claim 1 , wherein the vehicle-based transaction is triggered based on the position location being at a predetermined location, and the vehicle-based transaction is a parking session.

15. The location device of claim 14 , wherein the predetermined location is a legal parking zone.

16. The instructions further include: determining that the vehicle is moving faster than a predetermined speed; causing the geo-mapping server to transmit a message indicating that the vehicle is traveling faster than the predetermined speed; terminating the parking session based on the transmitted message.

15. The location device of claim 14.

17. The location device of claim 1 , wherein the vehicle-based transaction is a toll collection transaction that automates toll payment based on the position location of the vehicle.

18. 1. A method for processing a vehicle location, comprising: receiving global navigation satellite system (GNSS) data and vehicle motion data, the GNSS data and the vehicle motion data being associated with a vehicle; calculating, in an estimation filter operating in a first mode, a location of the vehicle based on the GNSS data and the vehicle motion data; determining when a speed of the vehicle is below a threshold speed; modifying the estimation filter to operate in a second mode based on the speed being below the threshold speed; calculating a position location of the vehicle in the estimation filter operating in the second mode, wherein at least some of the GNSS data and the vehicle motion data are modified so that the estimation filter determines the position location of the vehicle; and transmitting the position location of the vehicle to a geomapping server to enable vehicle-based transactions; A method comprising:

19. The method of claim 18 , wherein altering at least some of the GNSS data and the vehicle motion data causes the vehicle speed data to be altered.

20. The method of claim 18 , wherein altering at least some of the GNSS data and the vehicle motion data alters vehicle yaw rate data.

21. The method of claim 18 , further comprising: calculating and capturing a plurality of location points when the estimation filter is operating in the second mode.

22. The velocity of the vehicle is a first velocity value received in the GNSS data, and the method further comprises: receiving one or more signal strength indicators in the GNSS data; determining not to use the first speed value from the one or more signal strength indicators; calculating a second velocity value based at least in part on the vehicle motion data; 20. The method of claim 18, further comprising:

23. The method of claim 22 , wherein the second velocity value is calculated at least in part using vehicle acceleration data from the vehicle motion data.

24. The method of claim 18 , wherein the estimation filter is a Kalman filter, the Kalman filter including multiple modes.

25. 20. The method of claim 18, wherein the vehicle-based transaction is triggered based on the position location being at a predetermined location, and the vehicle-based transaction is an energy dispensing session at an energy dispensing device.

26. 26. The method of claim 25, further comprising: enabling the energy dispensing session at the energy dispensing device using two-factor authentication, a first authentication factor based at least in part on the transmitted location and a second authentication factor based at least in part on a communication from a user device.

27. The method of claim 26 , wherein the communication from a user device identifies the energy dispensing device.

28. 27. The method of claim 26, wherein the energy dispensing device is a first energy dispensing device and the communication from a user device identifies a second energy dispensing device.

29. 20. The method of claim 18, wherein the energy dispensing device is a fuel pump.

30. 20. The method of claim 18, wherein the energy dispensing device is an electric vehicle charger.

31. 20. The method of claim 18, wherein the vehicle-based transaction is triggered based on the position location being at a predetermined location, and the vehicle-based transaction is a parking session.

32. 32. The method of claim 31, wherein the predetermined location is a legal parking zone.

33. determining that the vehicle is moving faster than a predetermined speed; sending a message to the geo-mapping server indicating that the vehicle is traveling faster than the predetermined speed; terminating the parking session based on the transmitted message.

32. The method of claim 31 , further comprising:

34. 20. The method of claim 18, wherein the vehicle-based transaction is a toll collection transaction that automates toll payment based on the position location of the vehicle.

Images