FreshPatents.com Logo
stats FreshPatents Stats
n/a views for this patent on FreshPatents.com
Updated: September 07 2014
newTOP 200 Companies filing patents this week


    Free Services  

  • MONITOR KEYWORDS
  • Enter keywords & we'll notify you when a new patent matches your request (weekly update).

  • ORGANIZER
  • Save & organize patents so you can view them later.

  • RSS rss
  • Create custom RSS feeds. Track keywords without receiving email.

  • ARCHIVE
  • View the last few months of your Keyword emails.

  • COMPANY DIRECTORY
  • Patents sorted by company.

Follow us on Twitter
twitter icon@FreshPatents

History timeline display for vehicle fleet management

last patentdownload pdfdownload imgimage previewnext patent


20130007626 patent thumbnailZoom

History timeline display for vehicle fleet management


A vehicle management system can generate a vehicle management user interface that depicts vehicle history information in timelines or graphical timelines. These history timelines can include information regarding vehicle location, speed, and idling, among other useful information. The graphical nature of the history timelines can quickly convey vehicle tracking details and potential problems, such as idling and congregation, to an administrator. Further, history timelines for multiple vehicles can be displayed in parallel, allowing comparison between histories for different vehicles.
Related Terms: User Interface Graph Vehicle Location

Inventors: Nathan Adams, Jason Koch, Howard Jelinek
USPTO Applicaton #: #20130007626 - Class: 715738 (USPTO) - 01/03/13 - Class 715 
Data Processing: Presentation Processing Of Document, Operator Interface Processing, And Screen Saver Display Processing > Operator Interface (e.g., Graphical User Interface) >For Plural Users Or Sites (e.g., Network) >Network Resource Browsing Or Navigating

Inventors:

view organizer monitor keywords


The Patent Description & Claims data below is from USPTO Patent Application 20130007626, History timeline display for vehicle fleet management.

last patentpdficondownload pdfimage previewnext patent

RELATED APPLICATION

This application claims the benefit of priority under 35 U.S.C. §120 as a continuation of U.S. patent application Ser. No. 13/251,129, filed Sep. 30, 2011, and issuing as U.S. Pat. No. 8,275,508 on Sep. 25, 2012, which claims priority under 35 U.S.C. §119(e) to U.S. Provisional Patent Application No. 61/449,044, filed on Mar. 3, 2011, entitled “History Timeline Display for Multiple Vehicles,” the disclosure of both of which is hereby incorporated by reference in its entirety.

BACKGROUND

Specialized fleet management software is often used to manage fleets of vehicles, such as trucks or taxis. Typical fleet management systems include functionality for mapping and tracking vehicles. Vehicle tracking is facilitated by communicating with tracking devices installed in vehicles, which typically obtain location and speed information using a global positioning system (GPS). The tracking devices can upload the location and speed information to the fleet management system. In turn, the fleet management system generates a user interface accessible by a fleet administrator to determine vehicle locations, routes, speeds, and so forth.

Some fleet management systems provide historical information about vehicle routes. Such historical information can include start and stop information, vehicle locations at given times, and speed information, or the like. A fleet management system typically outputs this historical information in the form of a list. For example, a fleet management system might provide a map display that includes symbols representing vehicles in a vehicle fleet, and user selection of a vehicle symbol can cause a popup window to display a vehicle history list.

SUMMARY

In certain embodiments, a system for providing history information for a plurality of vehicles includes a computer system including computer hardware programmed to implement a user interface module. The user interface module can at least: receive telematics data corresponding to a plurality of vehicles in a vehicle fleet, the telematics data including location information for the vehicles over time; generate a vehicle management user interface including data representing the plurality of vehicles; output the vehicle management user interface for presentation to a user, where the vehicle management user interface includes a map depicting the plurality of vehicles for selection by the user; receive a selection by the user of first vehicle data from the vehicle management user interface, where the first vehicle data represents a first vehicle of the plurality of vehicles; in response to receiving the selection of the first vehicle data, outputting a first vehicle history timeline including first vehicle status data reflecting at least a portion of the telematics data corresponding to the first vehicle; receiving a second selection by the user of second vehicle data from the vehicle management user interface, the second vehicle data representing a second vehicle of the plurality of vehicles; and in response to receiving the second selection of the second vehicle data, outputting a second vehicle timeline including second vehicle status data reflecting at least a portion of the telematics data corresponding to the second vehicle, the second vehicle timeline able to be displayed together with the first vehicle timeline such that the first and second vehicle timelines can be correlated in time, thereby enabling a visual comparison of the first and second vehicle status data.

A vehicle history user interface for providing history information for a plurality of vehicles can include: a first vehicle history timeline including first vehicle status data corresponding to a first vehicle, the first vehicle status data reflecting first location data obtained from the first vehicle; a second vehicle history timeline including second vehicle status data corresponding to a second vehicle, the second vehicle status data reflecting second location data obtained from the second vehicle; where the first and second vehicle history timelines can be displayed together on the same time scale; and where the vehicle history user interface is that can be generated by a computer system including computer hardware.

Non-transitory physical computer storage can be provided that includes instructions stored thereon for implementing, in one or more processors, a method of providing history information for a plurality of vehicles. The method can include: presenting a vehicle management user interface to a user, the vehicle management user interface including vehicle data representing a plurality of vehicles; receiving a user selection of the vehicle data for at least two vehicles; in response to receiving the user selection, obtaining vehicle status data over a given time period for each of the at least two vehicles; constructing vehicle history timelines for each of the at least two vehicles, where each vehicle history timeline includes the vehicle status data corresponding to one of the at least two vehicles; and outputting the vehicle history timelines for display to the user, where the vehicle history timelines are that can be displayed together on the same time scale.

In certain embodiments, a system for providing history information for a plurality of vehicles includes: a computer system including computer hardware programmed to implement a history module that can at least: obtain first vehicle status data for a given time period corresponding to a first vehicle, the first vehicle status data reflecting telematics data obtained from the first vehicle; obtain second vehicle status data for the same time period corresponding to a second vehicle, the second vehicle status data reflecting telematics data obtained from the second vehicle; construct a first history timeline including the first vehicle status data; construct a second history timeline including the second vehicle status data; and output the first and second history timelines together for presentation to a user.

In certain embodiments, the systems and methods herein can be used to track hundreds, thousands, or even tens of thousands of vehicles or more. The systems and methods herein can be implemented automatically and/or in real time. Thus, the systems and methods described herein are not, in their entirety, able to be implemented as mental processes.

The systems and methods described herein can be implemented by a computer system including computer hardware. The computer system may include one or more physical computing devices, which may be geographically dispersed or co-located.

Certain aspects, advantages and novel features of the inventions are described herein. It is to be understood that not necessarily all such advantages may be achieved in accordance with any particular embodiment of the inventions disclosed herein. Thus, the inventions disclosed herein may be embodied or carried out in a manner that achieves or selects one advantage or group of advantages as taught herein without necessarily achieving other advantages as may be taught or suggested herein.

BRIEF DESCRIPTION OF THE DRAWINGS

The features of embodiments of the inventions disclosed herein are described below with reference to the drawings. Throughout the drawings, reference numbers are re-used to indicate correspondence between referenced elements. The drawings are provided to illustrate embodiments of the inventions described herein and not to limit the scope thereof.

FIG. 1 illustrates an embodiment of a vehicle management system.

FIG. 2 illustrates an embodiment of a vehicle history generation process that can be implemented by the vehicle management system of FIG. 1.

FIGS. 3-8 illustrate embodiments of user interfaces associated with vehicle history displays that can be generated by the vehicle management system.

DETAILED DESCRIPTION

I. Introduction

As mentioned above, fleet vehicle history information is typically presented in the form of a list having events obtained from vehicle tracking devices. While a list of historical information can be useful, the list format also has drawbacks. For instance, history lists for different vehicles are typically uncorrelated in time and provide no easy way for a user to compare events occurring with respect to multiple vehicles. It can therefore be difficult and time consuming to identify problems such as congregations, where multiple drivers or vehicles congregate in one location, potentially to waste company time. Another drawback to the list format for displaying vehicle histories is that the common practice of vehicle idling, which wastes fuel, may be difficult to identify. Further, a list does not provide an easy way for a fleet administrator to quickly scan a history for various vehicle problems.

Advantageously, this disclosure describes a new vehicle history format for vehicle management systems that, in certain embodiments, addresses at least some of the aforementioned problems. The vehicle history format described herein can also provide additional advantages and benefits. In certain embodiments, a vehicle management system generates a vehicle management user interface that depicts vehicle history information in timelines or graphical timelines. These history timelines can include information regarding vehicle location, speed, and idling, among other useful information. The graphical nature of the history timelines can quickly convey vehicle tracking details and potential problems, such as idling and congregation, to an administrator. Further, history timelines for multiple vehicles can be displayed in parallel, allowing comparison between histories for different vehicles.

The features described herein may also be implemented for non-fleet vehicles, such as for personal vehicles having in-vehicle navigation systems. However, for ease of illustration, the remainder of this disclosure will describe vehicle management systems in the context of vehicle fleets, such as fleets of service vehicles, trucks, taxis, planes, boats, snow mobiles, emergency vehicles, other vehicles, and the like.

II. Vehicle Management System

FIG. 1 illustrates an embodiment of a computing environment 100 for implementing a vehicle management system 110. Among other features, the example vehicle management system 110 shown can generate a vehicle management user interface that includes vehicle history timelines.

In the computing environment 100, one or more in-vehicle devices 105A . . . 105N and management devices 135 communicate with the vehicle management system 110 over a network 145. The in-vehicle devices 105 can include computing devices installed in fleet vehicles. These devices 105 can include navigation functionality, routing functionality, and the like. The in-vehicle devices 105 can receive route information and other information from the vehicle management system 110. In addition, the in-vehicle devices 105 can report information to the vehicle management system 110, such as driver location, vehicle sensor data, vehicle status (e.g., maintenance, tire pressure, or the like), and so forth.

The management devices 135 can be computing devices used by dispatchers, fleet managers, administrators, or other users to manage different aspects of the vehicle management system 110. For example, a user of a management device 135 can access the vehicle management system 110 to generate routes, dispatch vehicles and drivers, and perform other individual vehicle or fleet management functions. With the management devices 135, users can access and monitor vehicle information obtained from one or more of the in-vehicle devices 105 by the vehicle management system 110. Such vehicle status information can include data on vehicle routes used, stops, speed, vehicle feature usage (such as power takeoff device usage), driver behavior and performance, vehicle emissions, vehicle maintenance, energy usage, and the like. In some embodiments, the management devices 135 are in fixed locations, such as at a dispatch center. The management devices 135 can also be used by administrators in the field, and may include mobile devices, laptops, tablets, smartphones, personal digital assistants (PDAs), desktops, or the like.

The vehicle management system 110 can be implemented by one or more physical computing devices, such as servers. These servers can be physically co-located or can be geographically separate, for example, in different data centers. In one embodiment, the vehicle management system 110 is implemented as a cloud computing application. For instance, the vehicle management system 110 can be a cloud-implemented platform hosted in one or more virtual servers and/or physical servers accessible to users over the Internet or other network 145. In the depicted embodiment, the vehicle management system 110 includes a fleet management module 112, a mapping module 115, a telematics module 120, a routing module 130, a dispatch module 140, and an integration module 150. These components can, but need not, be integrated together on a common software or hardware platform.

The fleet management module 112 can include functionality for generating, rendering, or otherwise displaying a vehicle management user interface 114. The vehicle management user interface 114 can include a map or list of vehicles that depicts symbols or other data representative of vehicles. In addition, the vehicle management user interface 114 can advantageously include a history timeline display 116. For example, in response to user selection of one or more of the vehicle symbols from the map or list, the vehicle management user interface 114 can output one or more vehicle history timelines corresponding to the selected vehicle or vehicles. Advantageously, the history timeline display 116 can provide multiple vehicle histories correlated in time or event, thereby allowing comparison of events among vehicles. Viewed another way, the vehicle history timelines can also be considered driver history timelines.

Example vehicle management user interfaces 114 and history timeline displays 116 are described below in detail with respect to FIGS. 3 through 8. Although the fleet management module 112 generates the user interface 114, in certain embodiments the fleet management module 112 outputs the user interface 114 to the management devices 135, which actually display the user interface 114 and associated history timeline display 116. Thus, as used herein, the terms “output a user interface for presentation to a user,” “presenting a user interface to a user,” and the like, in addition to having their ordinary meaning, can also mean (among other things) transmitting user interface information over a network, such that a user device can actually display the user interface.

The fleet management module 112 can communicate with the mapping module 115 to obtain mapping data, which the fleet management module 112 can include in the vehicle management user interface 114. The mapping data can be compressed, transmitted, re-rendered, and displayed on the management user interface 114. Other data can also be overlaid to enhance the map and management layout. The mapping module 115 can be a geographic information system (GIS) in one embodiment. The fleet management module 112 can also access the telematics module 120 to obtain vehicle status data for inclusion in vehicle history timelines. The telematics module 120 can provide this vehicle status data based on telematics data obtained from the in-vehicle devices 105N. The telematics data can include such data as location or speed information obtained using GPS or cellular tower triangulation (or other methods), vehicle sensor data, solid state inertial information, or any other data that can be obtained from a vehicle, its engine, or the like (including other sensors such as passenger seat sensors to detect the presence of passengers and so forth). The telematics data is described below in greater detail with respect to FIG. 2.

The routing module 130 can construct pre-dispatch or post-dispatch routes for vehicles based on any of a variety of routing algorithms, such as those disclosed in U.S. Publication No. 2010/0153005, filed Dec. 8, 2009, and entitled “System and Method for Efficient Routing on a Network in the Presence of Multiple-Edge Restrictions and Other Constraints,” the disclosure of which is hereby incorporated by reference in its entirety. In addition, the routing module 110 can automatically select routes that take into account factors that affect energy usage using the techniques described in U.S. application Ser. No. 12/954,547, filed Nov. 24, 2010, and entitled “Vehicle Route Selection Based on Energy Usage,” the disclosure of which is hereby incorporated by reference in its entirety.

The integration module 130 can facilitate integration of the vehicle management system 110 with other systems, such as fuel card systems, payroll systems, supply chain system, insurance systems, and the like. The dispatch module 140 can provide functionality for users of the management devices 135 to assign drivers and vehicles to routes selected by the routing module 110.

Furthermore, although not shown, the vehicle management system 110 may include functionality for disabling an engine remotely to recover a stolen vehicle (as permitted in Europe and some other areas).

The illustrated network 145 may be a LAN, a WAN, the Internet, combinations of the same, or the like. For ease of illustration, the vehicle management system 110 has been depicted as a centralized system. However, in other implementations, at least some of the functionality of the vehicle management system 110 is implemented in other devices. Other possible implementations of the vehicle management system 110 can include many more or fewer components than those shown in FIG. 1.

III. History Timeline Generation Features

With reference to FIG. 2, an embodiment of a vehicle history generation process 200 is illustrated. The vehicle history generation process 200 can be implemented by the vehicle management system 110. In particular, the vehicle history generation process 200 can be implemented by the fleet management module 112. In certain embodiments, the vehicle history generation process 200 advantageously generates a vehicle management user interface having a history timeline display. The vehicle history generation process 200 will be described in the context of FIG. 3, which includes an example vehicle management user interface.

At block 215 of FIG. 2, a vehicle management user interface is presented to a user. The user may be an administrator or other user of the management devices 135 described above. The vehicle management user interface may be presented to the user in response to the user requesting access to the vehicle management user interface. For instance, in one embodiment, the user accesses a browser or other network application software installed on a management device 135, which accesses the vehicle management user interface 114 from the vehicle management system 110. The vehicle management user interface 114 can therefore run in a browser, for example, as a web page or the like. The vehicle management user interface 114 could run instead in an application other than a browser in other embodiments.

Turning to FIG. 3, an example vehicle management user interface 300 is shown. The vehicle management user interface 300 includes a map 301 having various symbols 302, 304 that represent vehicles. Two main types of vehicle symbols 302, 304 are shown to represent single vehicles and groups or clusters of vehicles. The symbols 302 include green arrows to indicate movement of a vehicle, blue idle signs to indicate a vehicle that is idling, and red stop signs that indicate vehicles that have stopped. These symbols are merely illustrative examples and can be varied in other embodiments. The symbols 304, in contrast, represent groups or clusters of vehicles. If a user were to zoom in on a cluster 304, the cluster could expand to show individual vehicles (or smaller clusters, should the original cluster 304 represent a large number of vehicles). The vehicle management user interface 300 can therefore incorporate the clustering features described in detail in U.S. application Ser. No. 12/882,930, filed Sep. 15, 2010, and entitled “Real Time Map Rendering With Data Clustering and Expansion and Overlay,” the disclosure of which is hereby incorporated by reference in its entirety. Clusters need not be used to represent groups of vehicles, however.

User selection of an individual vehicle symbol 302 or cluster 304 can cause the vehicle management user interface 300 to produce a popup box 310 displaying certain vehicle status information. The example vehicle status information shown in the popup box 310 includes vehicle identifiers 312, addresses of current locations, icons representing the current status of the vehicles (such as green boxes to represent moving, stop signs for stopped vehicles, idle signs etc.). Further, the popup box 310 includes links 314, 316 for adding one or more vehicles to a history display. Selection of the link 314, which says “Add to History” underneath a specific vehicle identifier 312, can add an individual vehicle to a history display. Selection of the link 316, which says “Add all to history,” can add all the vehicles shown in the box 310 and corresponding to the selected cluster 304 to a history display.

A history timeline display is not shown in FIG. 3 but can be generated from the vehicle management user interface 300 shown in FIG. 3 (see FIG. 4). Toolbars 305, 330 are included as examples of user interface controls that can be used to manage history timeline displays 116. For example, in the toolbar 330, another way to select vehicles to add to a history display is to enter the name of the vehicle in a text box 340 and select an “add unit” button 342. A date for which history can be displayed is also selectable via control 338 in the toolbar 330. Further, the toolbar 330 includes a checkbox control 332 for toggling the history display or history layer. A select box 334 allows current data, key events, and/or all vehicle status data to be displayed on a history timeline. A select box 336 allows different types of timelines to be generated (see below). On the toolbar 305, different buttons 322, 324, and 326 enable different formats for the history display, such as in a frame below the map 301, in a frame to the right (or left) of the map 301, or as a list independent of the map 301. Further, the history display can be provided in a separate window.

Referring again to FIG. 2, it is determined at decision block 225 whether a user selects one or more vehicles to add to a history display. If the user makes no selection, the process 300 effectively loops until a selection is performed. Thus, for example, a history display would be generated in one embodiment if one of the links 314, 316 of FIG. 3 were selected. If the user does select a vehicle or vehicles, at block 225, a vehicle history display is generated using blocks 235 through 255 of the process 300.

At block 235, vehicle status data over a given time period is obtained for each vehicle selected. The time period over which vehicle status data is obtained can be a day, a week, an hour, or the like. The time period can be the current 24-hour period, for instance. History timelines can also be generated for previous days or other past time periods.

The vehicle status data acquired by the telematics module 120 can be obtained by the fleet management module 112. As described above, the telematics module 120 can obtain telematics data from in-vehicle devices 105 or from extra-vehicle devices or locations. Telematics data can include raw vehicle sensor data, such as engine sensor data (which can reflect whether a vehicle is running/idling or turned off), power takeoff device data (which can reflect whether a hydraulic device is operating—see below with respect to FIG. 7), and the like. Further, the telematics data can include raw GPS receiver data (such as latitude, longitude, elevation, and time data).

The telematics module 120 can translate this telematics data into more human-readable vehicle status data, which is accessed at block 225 of the process 300. For instance, the telematics module 120 can translate engine sensor data into information regarding vehicle stop and idle times and information regarding whether a power takeoff device (such as a hydraulic lift) was in use while an engine was running (see below with respect to FIG. 7). As another example, the telematics module 120 can access the GIS software of the mapping module 120 to translate GPS or cellular triangulation data to street address information. In other embodiments, however, the in-vehicle devices can translate the telematics data into the human-readable vehicle status data.

A vehicle history timeline is constructed for each selected vehicle at block 245, and the vehicle history timelines are output together on the same time scale at block 255. Constructing a vehicle history timeline can include accessing or generating graphic elements corresponding to the vehicle status data and arranging the graphic elements together, optionally with text, in a timeline format. The timelines can be constructed in the form of horizontal or vertical bar graphs in one embodiment. Each bar graph can represent a timeline for a specific vehicle. Other formats, including formats that involve solely text rather than graphics, are also possible. For example, the timeline could be in the form of a table, chart, or other data having symbols whose size, color, and/or information included therein change over time. In some embodiments, one or more timelines constitute a Gantt chart or the like.

The selection and arrangement of graphical and textual elements of the timelines can also depend on preferences selected by a user. For instance, a user can select different types of history timelines or history timelines that show different types of status data. In one embodiment, different timelines can be constructed for the same vehicle to reflect different data. Some examples of such data can include information regarding vehicle stop, moving, and idle times, information regarding congregations, warnings regarding policy violations (such as speeding, operating a power takeoff device while moving, or entering or approaching a geofenced (e.g., prohibited) area), and the like. Graphic elements can be used to represent these and other timeline features. Text may also be overlaid over the graphics elements to provide prompting as to the meaning of the graphics elements.

As an example, several vehicle history timelines are shown in FIG. 4. By way of overview, FIG. 4 represents one possible vehicle management user interface 400 that can be generated in response to the “Add all to History” link 316 being selected in FIG. 3. As described above, this link 316 enables each of the vehicles in the popup box 310 of FIG. 3 to be added to a history display. Such a history display 450 is shown in FIG. 4, including a list of the vehicles 451 for which the display 450 is generated and their corresponding history timelines 460.

Similar to the vehicle management user interface 300, the vehicle management user interface 400 includes a map 401. The map 401 depicts routes taken by the vehicles 451 that are the subject of the history display 450. Upon addition of the vehicles 451 to the history display 450, the map 401 has zoomed into an area that depicts routes 468 taken by the vehicles. The routes 468 are illustrated by dashed lines having colors that are also shown in colored circles 453 next to names 454 of the vehicles 451. In one embodiment, these colors 453 are automatically assigned to the vehicles 451 upon insertion into the history display 450. Advantageously, this automatic color assignment can facilitate easier visual associations between the vehicles 451 and their respective routes 468. The colors can be assigned by a random or deterministic algorithm by the fleet management module 112. Further, a control 459a is included for removing vehicles 451 from the history display 450. Similarly, a control 452 is also included on the map for removing the history layer.

The toolbars 305, 330 are also included from FIG. 3 and include all the functionality described above with respect to FIG. 3. The select box 336 indicates that the timelines are to be colored or color-coded according to unit status, which can be an (optionally) default type of history timeline 460 or custom history timeline configuration. The unit status type of timeline can reflect a general status of the units, or vehicles 451, shown in the history display 450. Accordingly, in the depicted embodiment, the history timelines 460 each reflect general status information about the vehicles 451, such as moving, stopped, and idle times, as well as other information.



Download full PDF for full patent description/claims.

Advertise on FreshPatents.com - Rates & Info


You can also Monitor Keywords and Search for tracking patents relating to this History timeline display for vehicle fleet management patent application.
###
monitor keywords



Keyword Monitor How KEYWORD MONITOR works... a FREE service from FreshPatents
1. Sign up (takes 30 seconds). 2. Fill in the keywords to be monitored.
3. Each week you receive an email with patent applications related to your keywords.  
Start now! - Receive info on patent apps like History timeline display for vehicle fleet management or other areas of interest.
###


Previous Patent Application:
Apparatus, system, and method for connecting mobile devices to a backend server in an enterprise software environment and initiating a business process
Next Patent Application:
Presenting entity profile information to a user of a computing device
Industry Class:
Data processing: presentation processing of document
Thank you for viewing the History timeline display for vehicle fleet management patent info.
- - - Apple patents, Boeing patents, Google patents, IBM patents, Jabil patents, Coca Cola patents, Motorola patents

Results in 0.73659 seconds


Other interesting Freshpatents.com categories:
Computers:  Graphics I/O Processors Dyn. Storage Static Storage Printers

###

Data source: patent applications published in the public domain by the United States Patent and Trademark Office (USPTO). Information published here is for research/educational purposes only. FreshPatents is not affiliated with the USPTO, assignee companies, inventors, law firms or other assignees. Patent applications, documents and images may contain trademarks of the respective companies/authors. FreshPatents is not responsible for the accuracy, validity or otherwise contents of these public document patent application filings. When possible a complete PDF is provided, however, in some cases the presented document/images is an abstract or sampling of the full patent application for display purposes. FreshPatents.com Terms/Support
-g2-0.265
     SHARE
  
           

FreshNews promo


stats Patent Info
Application #
US 20130007626 A1
Publish Date
01/03/2013
Document #
13610679
File Date
09/11/2012
USPTO Class
715738
Other USPTO Classes
International Class
06F3/01
Drawings
9


User Interface
Graph
Vehicle Location


Follow us on Twitter
twitter icon@FreshPatents