Route management for vehicle fleets

Abstract

Systems and methods are provided for performing improved route management. For example, systems access trip data structures associated with different trips and identify an overlapping trip portion that is common to each of the different trips. Systems divide the overlapping trip portion into route segments and identify at least one alternate segment for each route segment. After generating different combinations of the route segments and alternate route segments, systems determine a route valuation for each route combination and identify a preferred route combination. The trip data structures are then modified by replacing the overlapping trip portion with the preferred route combination. Finally, a new trip route is generated for each of the different trips.

Description

ROUTE MANAGEMENT FOR VEHICLE FLEETS BACKGROUND

[0001] There are many different types of companies that manage fleets of vehicles for various purposes. Some vehicle fleets are purposed as passenger vehicles, while other fleets are purposed for delivery and cargo. Transport and delivery companies manage fleets of vehicles comprising vehicles driven by various drivers employed by the companies. In some instances, these vehicle fleet owners outsource the management of their fleet to a fleet manager. In these instances, the fleet manager is in charge of managing several vehicle fleets across multiple customers.

[0002] Whether individually managed or managed by a third party, there are many different components of fleet management. For example, each vehicle must be equipped with a transponder which is read at various toll checkpoints. In some cases, vehicles have multiple transponders in order to travel different sets of tolled routes owned and operated by different toll companies. As these vehicles travel on tolled routes, they incur toll fees which are reflected in the toll bill(s) received from one or more toll agencies. Many different vehicles in a vehicle fleet travel hundreds of routes per week. In some instances, the current routes may be costing customers more time or more money than other available routes. However, because routes vary by starting and ending location, as well as by day of week / time of day, it is difficult to manage routes across the different vehicle fleets.

[0003] Accordingly, there is an ongoing need and desire for improved systems, methods, and devices for fleet management, particularly, for improved systems, methods, and devices that can be utilized for dynamic route management.

[0004] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate one exemplary technology area where some embodiments described herein may be practiced.BRIEF SUMMARY

[0005] Disclosed embodiments include systems, methods, and devices that can be utilized to facilitate fleet management, including for route management.

[0006] Some disclosed embodiments are directed to systems and methods for performing route management. For example, systems access trip data structures are associated with different trips that are taken by various vehicles in a vehicle fleet. The data structures identify different starting and ending locations of the corresponding plurality of- Page 1 - Docket No. 3400.408AWOtrips associated with traversable road infrastructures. Systems then analyze the trip data structures in order to identify an overlapping trip portion that is included within each of the plurality of trips. The overlapping trip portions includes a common first location and a common second location within each of the plurality of trips.

[0007] Next, the systems divide the overlapping trip portion into a plurality of route segments and identify, for each route segment of the plurality of route segments, one or more alternate segments. Based on the route segments and the alternate segments, systems generate a plurality of route combinations. Notably, each route combination of the plurality of route combinations comprises at least one route segment and at least one alternate segment. Additionally, each route combination of the plurality of route combinations extends between the common first location and the common second location.

[0008] After generating the set of possible route combinations, systems determine a route valuation for each route combination of the plurality of route combinations. Then, based on comparing the route valuation for each route combination against one or more route criteria, the system selects a preferred route combination. Each of the plurality of trip data structures is then modified by replacing the overlapping trip portion with the preferred route combination within each of the plurality of trip data structures. Finally, a new trip route is generated for each of the modified trip data structures.

[0009] Some systems and methods are also directed to filtering the plurality of route combinations based on different user-defined route constraints. The preferred route combination is then selected from the filtered route combination set.

[0010] Additional systems and methods are provided for performing dynamic, realtime route management. For example, systems identify a trip data structure that identifies a corresponding trip comprising a first location and a second location. In some instances, this corresponding trip is an imminent trip that is about to be taken by a particular driver / vehicle. The system then divides the trip into a plurality of route segments and identifies one or more alternate segments for each route segment of the plurality of route segments.

[0011] Systems generate a segment valuation for each route segment of the plurality of route segments and for any alternate segments and identify at least one alternate segment that is associated with a higher segment valuation than its corresponding route segment. Subsequently, systems identify one or more toll gantries associated with the corresponding route segment and label the one or more toll gantries as exclusion zones. By identifying these exclusion zones, the system is able to modify the trip data structure with instructions- Page 2 - Docket No. 3400.408AWOto avoid the exclusion zones, thereby forcing the route management system to identify improved routes that yield higher route valuations. The systems then transmit the updated trip data structure to a vehicle routing device in communication with the computing system. This updated trip data structure can then be displayed on a driver -facing user interface. Beneficially, this analysis can be performed in real-time such that the user interface can be modified with the most up-to-date version of the trip data structure based on any new real-time data that is available for the trip route.

[0012] This Summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0013] Additional features and advantages will be set forth in the description that follows, and in part will be obvious from the description, or may be learned by the practice of the teachings herein. Features and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. Features of the present invention will become more fully apparent from the following description and appended claims or may be learned by the practice of the invention as set forth hereinafter.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] In order to describe the manner in which the above-recited and other advantages and features can be obtained, a more particular description of the subject matter briefly described above will be rendered by reference to specific embodiments that are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments and are not therefore to be considered to be limiting in scope, embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

[0015] Fig. 1 illustrates an example architecture of a flow diagram for facilitating an improved fleet management system.

[0016] Fig. 2 illustrates an example diagram of the distribution of fleet management.

[0017] Fig. 3 illustrates an example architecture that includes a computing system that includes and / or that is capable of being utilized to implement the disclosed embodiments.

[0018] Fig. 4A illustrates an example embodiment of a user portal.

[0019] Fig. 4B illustrates an example embodiment of a correlated dataset.- Page 3 - Docket No. 3400.408AWO

[0020] Fig. 4C illustrates an example embodiment of a correlated trip dataset.

[0021] Fig. 5 illustrates example embodiments of discrepancies and errors found between toll transaction data and telemetric data.

[0022] Fig. 6 illustrates various example embodiments of different types of user portals.

[0023] Figs. 7A-7D illustrates an example embodiment of a flow diagram for building a backend database of toll agencies and corresponding sensor checkpoints.

[0024] Figs. 8A-8F illustrate various user interfaces associated with the flow diagram illustrated in Figs. 7A-7D.

[0025] Fig. 9 illustrates a process flow diagram comprising a plurality of acts associated with a method for generating a correlated trip dataset.

[0026] Fig. 10 illustrates a process flow diagram comprising a plurality of acts associated with a method for generating a net present toll value.

[0027] Fig. 11 illustrates a process flow diagram comprising a plurality of acts associated with a method for reassigning one or more vehicle tags.

[0028] Fig. 12 illustrates a process flow diagram comprising a plurality of acts associated with a method for identifying discrepancies between toll transaction data and fleet telematics data.

[0029] Fig. 13 illustrates a process flow diagram comprising a plurality of acts associated with a method for identifying fraud and abuse of a fleet vehicle.

[0030] Fig. 14 illustrates a process flow diagram comprising a plurality of acts associated with a method for generating a correlated dataset.

[0031] Fig. 15 illustrates an example overview of a rental vehicle along a trip route during a rental period.

[0032] Fig. 16 illustrates an example triggering event for generating a rental invoice with an estimated total toll fee along with the rental fee.

[0033] Fig. 17 illustrates an example process flow diagram for communication between a vehicle, a telematics server, and a rental server.

[0034] Fig. 18 illustrates various example rental invoice displays, including the presentation of the estimated total toll fee and / or the rental fee.

[0035] Fig. 19 illustrates an example car interior, with various example embodiments for displaying an estimated running or total toll fee.- Page 4 - Docket No. 3400.408AWO

[0036] Fig. 20 illustrates a process flow diagram comprising a plurality of acts associated with a method for generating a rental invoice with an estimated total toll fee from the perspective of the telematics server.

[0037] Fig. 21 illustrates a process flow diagram comprising a plurality of acts associated with a method for generating a rental invoice with an estimated total toll fee from the perspective of the rental server.

[0038] Fig. 22 illustrates a process flow diagram comprising a plurality of acts associated with a method for generating and displaying real-time, or near-real-time, estimated toll transaction data.

[0039] Figs. 23A-23C illustrate various aspects of a route management software that identifies and evaluates different alternate routes for a set of trips routes that include an overlapping portion along a tolled road.

[0040] Fig. 24 illustrates an example of process flow diagram for determining a mixed trip route based on different tolled and non-tolled route segments.

[0041] Fig. 25 illustrates an example of a plurality of different possible mixed routes.

[0042] Fig. 26 illustrates an example of comparing different route options.

[0043] Fig. 27 illustrates an example of comparing different route options based on a day of the week and time of day.

[0044] Fig. 28 illustrates an example of different criteria, including different metrics, by which to optimize for the selection of the preferred route.

[0045] Fig. 29 illustrates an example of additional criteria, including constraints, by which to modify the selection of the preferred route.

[0046] Fig. 30 illustrates an example of a plurality of other factors that can be used to modify the selection of the preferred route.

[0047] Fig 31 illustrates an example of a user interface for facilitating dynamic route management.

[0048] Fig. 32 illustrates a process flow diagram comprising a plurality of acts associated with a method for dynamically generating and managing routes for a vehicle fleet.

[0049] Fig. 33 illustrates a process flow diagram comprising a plurality of acts associated with an alternate method for dynamically generating and managing routes for a vehicle fleet.- Page 5 - Docket No. 3400.408AWO

[0050] Fig. 34 illustrates a process flow diagram comprising a plurality of acts associated with a method for generating and modifying user interfaces that facilitate improved route management.DETAILED DESCRIPTION

[0051] Disclosed systems and methods can be utilized to facilitate fleet management, for example, by accessing toll transaction data received from one or more toll agencies, normalizing the toll transaction data from each toll agency, accessing telematic data, normalizing the telematic data, and generating correlated trip datasets comprising the normalized toll transaction data and the normalized telematic data. Disclosed systems and methods can also be utilized to facilitate rental fleet management, including the real-time and near-real-time generation of rental invoices that include estimated toll transaction data at the point of return of a rental vehicle.

[0052] The disclosed systems can also be utilized to use the correlated trip datasets to calculate net present toll values, identify toll bill errors, identify pre-violations, and identify vehicle fraud and abuse. Some systems are configured to identify customer fleets comprising a plurality of vehicles and to identify trips taken by the various vehicles included in the plurality of vehicles. The systems are also configured to access toll transaction data received from one or more toll agencies associated with the various fleet vehicles. The systems further access telematic data associated with the particular fleet vehicles which includes GPS coordinate data associated with the route(s) traveled by the particular vehicle(s) during the identified trip(s). After accessing the telematic data and the toll transaction data, the systems are configured to generate corresponding correlated trip datasets comprising the normalized toll transaction data and the normalized telematic data for the various vehicles / trips.

[0053] In some instances, prior to generating the correlated trip dataset, the systems are configured to normalize the toll transaction data and the telematic data such that the system is configured to identify data points in the toll transaction data that correlate with data points in the telematic data.

[0054] Some disclosed embodiments are also directed to methods for generating a net present toll value associated with a vehicle or vehicle fleet. In such embodiments, systems are configured to identify a customer fleet comprising a plurality of vehicles and access toll transaction data received from one or more toll agencies about the customer fleet. In addition to toll transaction data, the systems are also configured to access telematic data from the customer fleet. The telematic data includes a first set of GPS coordinate data- Page 6 - Docket No. 3400.408AWOassociated with tolled routes traveled by the plurality of vehicles and a second set of GPS coordinate data associated with non-tolled routes traveled by the plurality of vehicles. In such instances, the tolled routes and non-tolled routes have corresponding departure and arrival destinations. Based on at least comparing the first set of GPS coordinate data and the second set of GPS coordinate data, the systems generate a net present toll value configured to indicate whether the tolled route, along with its associated toll fees, meets a net present toll value threshold.

[0055] Some disclosed embodiments are also directed to systems and methods for generating a set of assigned vehicle tags. For example, some systems are configured to identify one or more customer fleets (each customer fleet comprises one or more vehicles). Systems then access toll transaction data about one or more customer fleets. The toll transaction data is received from one or more different toll agencies. The systems are also configured to access telematic data associated with the plurality of vehicles included in each customer fleet. The telematic data includes GPS coordinate data associated with routes traveled by one or more vehicles during trips taken by one or more vehicles. After accessing the various data, the systems are configured to normalize the toll transaction data and the telematic data such that the systems are able to identify data points in the toll transaction data that correlate with data points in the telematic data.

[0056] In addition to accessing toll transaction data and telematic data, systems access tag fee data from each of one or more agencies and a set of assigned vehicle tags associated with the different customer fleets. Once the various data have been normalized, the systems generate a correlated trip dataset comprising the normalized toll transaction data and the normalized telematic data. Based on comparing the correlated trip dataset and the tag fee data, systems are configured to determine whether one or more vehicle tags in the set of vehicle tags should be reassigned in order to maximize monetary savings. In response to determining that one or more vehicle tags should be reassigned, the systems reassign one or more vehicle tags and update the set of assigned vehicle tags based on the tag reassignment.

[0057] Some disclosed embodiments are also directed to systems and methods for identifying errors in toll transaction data. For example, systems are configured to identify a customer fleet comprising a plurality of vehicles and identify a trip taken by a particular vehicle included in the plurality of vehicles. The systems then access toll transaction data about the particular vehicle that has been received from one or more toll agencies. The systems normalize the toll transaction data from each toll agency according to a first pre-- Page 7 - Docket No. 3400.408AWOdetermined standard formatting. In addition to the toll transaction data, the systems also access telematic data associated with the particular data. The telematic data includes GPS coordinate data associated with a route traveled by a particular vehicle during the trip.

[0058] After accessing the telematic data, the systems are configured to normalize the telematic data according to a second pre-determined standard formatting which corresponds to the first pre-determined standard formatting such that the systems are able to identify data points in the toll transaction data that correlate with data points in the telematic data. The systems are also configured to identify one or more discrepancies between the normalized toll transaction data and the normalized telematic data and generate one or more error alerts to a user which correspond to one or more discrepancies.

[0059] Some disclosed embodiments are also directed to systems and methods for detecting abuse and fraud in vehicle fleet management, identifying a customer fleet comprising a plurality of vehicles. For example, systems are configured for identifying a trip taken by a particular vehicle included in the plurality of vehicles and accessing a planned route associated with the trip that was generated prior to a trip departure. Systems are also configured to access telematic data associated with the particular vehicle and normalize the telematic data such that the systems identify data points in the planned route that correlate with data points in the telematic data. Next systems identify one or more discrepancies between the planned route and the normalized telematic data and generate one or more error alerts corresponding to the one or more discrepancies. One or more error alerts are configured to be presented to a user.

[0060] The disclosed embodiments provide many technical advantages over existing systems, methods, and devices for fleet management. For example, the disclosed embodiments provide for improved systems and methods for toll bill error identification and dispute management. Conventional systems do not provide a way in which to identify bill errors based on telematic data gathered from the vehicle. Without the correlated dataset of toll transaction data and the telematic data, the customer or fleet manager is ill-equipped to dispute anything in the toll bill that is incorrect. Furthermore, because of the improved communication between the customers, fleet managers, and toll companies, system users are better able to manage violations, including avoiding additional future violations by identifying sources that have caused the previous violations.

[0061] System users are also able to see further analytics, including a net present toll value for the various tolled routes that drivers are taking. In this manner, system users (e.g., customers and / or fleet managers) are able to determine which tolls are worth paying in- Page 8 - Docket No. 3400.408AWOorder to achieve another goal (e.g., time savings). Because the toll transaction data can be correlated to historic telematic data as well as predicted telematic data (e.g., a planned route), system users are also able to quickly identify if any fraud is being committed against a customer by one of its drivers. Additionally, by comparing the toll transaction data with the predicted or historical telematic data, the system is able to identify fraud in the form of third-party tampering with or stealing a vehicle and / or vehicle transponder (e.g., if the transponder is in a different location than the vehicle and / or if the vehicle has taken an unauthorized route or abnormal route). These and many other benefits are described in further detail herein.

[0062] Attention will now be directed to Fig. 1, which illustrates an example embodiment of a flow diagram for a system (e.g., system 100) configured to facilitate improved fleet management. For example, Fig. 1 is shown having at least one electronic toll collection (ETC) network (e.g., ETC network 102), customers 122, payment processing systems 139, fleet management support and operations 118, and fleet management services 130.

[0063] The fleet management support and operations 118 further comprise a ticketing system 120, wherein administrators and customers can submit tickets for different requests - such as system updates, data updates, trouble-shooting assistance, etc. ETC networks are third-party networks / services that provide tolling services and are configured to generate toll transaction data for customers. The fleet management support and operations 118 also is configured to send requests / orders to tag manufacturers for tags to be manufactured and delivered to the fleet manager and / or customers.

[0064] The ETC network comprises one or more different toll agencies (e.g., toll agency 104) which manage different tolling systems implemented on various regions of road transportation infrastructure networks. The toll agency 104 manages at least one business account 106 which is a business account set up for a particular customer (e.g., customers 122) of the ETC network.

[0065] In some instances, all accounts associated with toll agency 104 belong to the fleet manager. Thus, there will be multiple customers on a toll agency account that the fleet manager owns. The fleet manager then separates the customer’s toll transaction on the backend and assigns transactions to the fleet manager’s customer accounts.

[0066] The toll agency 104 generates toll transaction data 108 for the customer, including toll bills for the customer associated with the business account 106. The toll agency also generates violation data (e.g., pre-violations 110 and violations in violations- Page 9 - Docket No. 3400.408AWOdatabase 154) associated with business account 106. For example, if a vehicle in the customer’s fleet has violated a toll agency protocol, toll agency 104 will generate a violation with a corresponding violation fee, in addition to the standard toll bills. These violations can be sent to fleet management support and operations 118 and / or directly to the customers 122.

[0067] In some instances, all agency and account relationships are with the fleet manager directly. In such instances, agencies do not send out pre-violations. However, there are ways to determine pre-violations by working with agencies before violations are sent. Depending on the type of violation, the violation will be sent to the fleet manager’s operation. Alternatively, if the customer is not identified as being associated with their fleet manager for some reason (i.e., stolen transponder) the violation will be sent directly to the customer based on the vehicle registration. Disclosed systems beneficially provide fleet managers with the ability to predict or detect some violations before an agency notifies anyone.

[0068] The toll agency 104 also receives and manages information about the tags 112 associated with a customer’s fleet, as well as any disputes 116 submitted by the customer and / or fleet manager. The disputes 116 include disputes over toll transaction data 108, including miscalculated toll bills and / or violations 114 that have been improperly cited. As previously discussed, toll agencies do not typically monitor errors in their collected toll transaction data and / or the generated toll bills and violations. Thus, it is the customer’s responsibility to review toll transaction data, including toll bills, and determine if there are any errors. If there are any errors, then the customer must contact the toll agency and submit a dispute for each item on the bill that they wish to resolve, have changed, or have removed.

[0069] However, in conventional systems, while toll agencies typically can provide the original toll transaction data upon which the toll bill is based, it is difficult to review and identify errors. The difficulty is compounded by the increasing complexity of the toll transaction data depending on the number of tolls, the size of the fleet, and the number of toll agencies being used. Thus, it is very difficult for customers to be able to review the toll bill and identify any errors, either in the calculation of the toll bill or errors that had been propagated from erroneously collected / recorded toll transaction data. It should be appreciated that some arrows between support and operations 118 and fleet management services 130 and other data are bidirectional arrows to indicate that some data is transmitted to the agency back office. For example, a vehicle list and / or other fleet data is- Page 10 - Docket No. 3400.408AWOshared between the customer system (and / or fleet management system) and the toll agency. Additional information about the fleet is also shared including vehicle plate numbers and / or tag assignment in some instances. Toll transaction data is also shared back and forth between the various systems via network communication or paper -trail communication (i.e., mail).

[0070] The disclosed embodiments are beneficially directed to systems and methods that provide customers and fleet managers with improved ways to analyze toll bills and violations in order to identify and dispute errors in the various toll transaction data. In addition, the disclosed embodiments allow customers and fleet managers to pre-emptively predict future violations and take preventative steps to mitigate the occurrence of such violations.

[0071] Attention will now be directed to Fig. 2, which illustrates an example embodiment of a fleet management hierarchy. Individual customers (e.g., Customer A, Customer B, etc.) own vehicle fleets (e.g., fleet 204, fleet 206, etc.) comprising one or more vehicles. In some instances, customers also manage their fleets through a customerfacing fleet management software or program (see fleet management software 124 as illustrated in Fig. 1). Where customers choose to manage their fleets, customers set up business accounts with the respective toll agencies, determine the tag assignments, receive toll bills and violations directly from the toll agency. In some instances, customers outsource the management of their fleets to a third-party company or service, such as a third-party fleet management system. Customers can also outsource billing / toll transaction data management to a third party, such as a bill or toll consolidator.

[0072] By implementing fleet management systems such as the one illustrated in Fig. 2, fleet managers, like fleet manager 202, are able to manage one or more vehicle fleets associated with one or more clients. In some instances, the fleet management company is then responsible for the business account registered with the toll agency, the tag assignment, and distribution. The toll agency is able to send the toll bill to the customer who forwards it to the fleet management company, or alternatively, the toll agency sends the toll bill directly to the fleet management company and / or the bill consolidator company. The fleet manager is able to access toll transaction data through the customer, the toll agency, and / or the toll consolidator. This is in contrast to conventional practices where companies handle toll invoices and manage relationships with toll agencies by themselves.- Page 11 - Docket No. 3400.408AWO

[0073] Thus, it will be appreciated that the toll transaction data, as related to disclosed embodiments herein, can be obtained directly or indirectly from one or more different sources. For example, the billing and / or toll transaction data can be obtained from a tolling agency, from a customer (e.g., a customer who previously received the toll transaction data from the tolling agency), from a third party, such as a fleet manager or a bill consolidator (e.g., a third-party who previously received the toll transaction data from the customer and / or one or more tolling agencies), or a combination thereof. Furthermore, it will be appreciated that disclosed embodiments described herein can be implemented in the context of a fleet manager and / or a toll consolidator.

[0074] As illustrated in Fig. 1, system 100 comprises fleet management services 130. The fleet management services 130 comprise various user portals (e.g., administrator portal 196 and customer portal 132). The administrator portal 196 is in network communication with fleet management support and operations 118. The customer portal 132 is configured with a BI embedding 134 and one or more fleet management add-ins 136. Each customer is set up with their customer portal which is either a standard interface or customized interface based on the specific customer needs. The customer portal 132 is configured to allow customers 122 to input various data and upload information about bills, fleets, tags, drivers, violations, and communications for the fleet manager. This data is accessed by the fleet management services 130 via customer data APIs 138. The customer data APIs 138 are equipped with a data sync 140 which is configured to push and pull data to and from the customer portal 132 and one or more other data sources.

[0075] The customer data APIs 138 are also configured with a telematics ETL (extract, transform, and load) system 142 which is configured to extract, transform, and load telematics data from the customer’s fleet management software (e.g., fleet management software 124). Examples of fleet management software include GeoTab, Salesforce, Samsora, etc. Such software systems are configured to record and collect telematics data about the customer’s fleet(s), including individual vehicle routes, vehicle information, overall fleet information, and driver information, along with other information (e.g., weather, traffic, gas prices, etc.).

[0076] The information and data that has been obtained via the customer data APIs 138 is then transmitted to and / or stored in various system locations, including a hardware storage device 150 configured to store one or more databases (e.g., dispute database 152, violations database 154, customer information database 156, vehicle information database 158, trip information database 160, pre-violations database 162, and toll rates database- Page 12 - Docket No. 3400.408AWO164. Data is also transmitted to and from other software services, including software analytics services 182, tag management services 184, tag procurement services 186, and disputes / violations services 188.

[0077] The business intelligence (BI) embedding 134 of the customer portal 132 is in communication with BI services 144 which is configured to transmit data stored in the customer portal 132 in order for the data to be analyzed. The analytics and reports data 146 are then used to provide software analytics services 182 (e.g., tolls, violations, saved time, etc.). The analytics and reports data 146 and further processed data provided through the software analytics services 182 are transmitted to and stored in one or more of the databases houses within hardware storage device 150. Additionally, toll transaction data 108 is extracted, transformed, and loaded (e.g., as vehicle / toll data 172 to ETL for Toll Bills 170) such that the data has been normalized prior to being stored in the trip information database 160. The toll transaction data 108 is organized by vehicle or fleets of vehicles.

[0078] Third-party map data (e.g., map data 168) is also obtained and stored in the trip information database 160. Prior to being stored, the map data is extracted, transformed, and loaded into system 100 (e.g., ETL for map data 166). Map data 168 comprises topographical, geographical, and political data (e.g., state / country lines) as well as transportation infrastructure data (e.g., routes and speed limits of roads, highways, etc.). Map data 168 also comprises historical and current weather data and historical and current traffic data, including construction zones and road closures. This information is used along with telemetric data for the different vehicles in order to identify errors in bills and violations, identify / predict pre-violations based on historical violations, procure, and assign tags, and provide toll value assessments (i.e., value assessments such as time and / or money saved). The various software services systems also utilize data retrieved from the administrator portal 196 via the administrator portal APIs 194. The ability to facilitate and manage tag assignments is important in order for the system to identify an assignment distribution that maximizes discounts based on what routes the different customers are sending their vehicles.

[0079] The trip data stored in the trip information database 160 is then used to generate bills, as part of billing services. These bills are then processed and paid for using payment processing systems 139. For example, the invoices will be generated based on the transactions that the toll agencies have recorded. The trip data will be used to ensure bill accuracy from the agency. The trip data will also be used to identify toll transactions and- Page 13 - Docket No. 3400.408AWOviolations, which can then be disputed with the agency if errors in either the toll bill or toll violations are found. Trip information is also configured to be used to predict toll bills, provide bill estimates, and identify any potential or future violations or issues.

[0080] By implementing fleet management systems, such as the fleet management system illustrated in Fig. 1, the invoices that are generated are improved invoices because they are based not just on the toll bills sent out by the tolling agencies, but also on comparing the toll transaction data from the toll bills against telematic data. By ensuring the toll bills are accurate, the system prevents errors from being propagated from the toll bill into the customer invoice. Thus, the customer received a reviewed invoice which has improved accuracy over invoices generated by conventional methods (e.g., invoices that are based on data that does not include a correlated toll transaction and telematics dataset).

[0081] Similar to the toll transaction data, pre-violations 110 are also extracted, transformed, and loaded into the system (e.g., ETL for Pre-Violations 174) prior to being stored in the pre-violations database 162 such that the pre-violation data, including delayed violations 176, is normalized according to a system standard. This improves the data analysis processes because all of the data stored in the various databases are in the same format. This improves the accuracy of any data comparisons and calculations, as well as reduces the amount of time required to perform the data comparisons and calculations.

[0082] The data comparisons and calculations, such as predicted toll bills are based, in part, on the toll rates 190 (e.g., as stored in toll rates database 164). Each toll agency sets its own toll rates for the various sensor checkpoints. These rates are also dynamically changing based on the time of day and / or time of year. For example, during heavy traffic (e.g., rush hour commute to and from the standard 9am-5pm workday) toll rates are increased. In contrast, low traffic (e.g., night-time) tolls are decreased. The fleet management support and operations 118 obtain and update the toll rates. Because each toll agency has its own rate structure, the toll rates that are obtained are in different formats. Thus, the disclosed embodiments beneficially extract, transform, and load the different toll rates into system 100 such that the toll rate data are normalized prior to being stored in the toll rates database 164. This improves downstream analysis and the use of the toll rate data by the different system services.

[0083] The toll rate data is further augmented / supplemented with integrated sensor checkpoint data which is used to map the different sensor checkpoints managed by different toll agencies into a single environment (e.g., computing environment 300). System 100 provides for interface 192 which is configured to allow users to upload sensor- Page 14 - Docket No. 3400.408AWOcheckpoint data and generate an integrated sensor checkpoint map (see Fig.7, Figs. 8A-8f and corresponding description, herein).

[0084] In some states and / or countries, multiple toll agencies own and operate different tolled infrastructure including roads, highways, and bridges which have different sensor checkpoints along the different routes. Thus, the integrated sensor checkpoint map comprises information from each of the toll agencies.

[0085] In some embodiments, the integrated sensor checkpoint map is a dataset comprising data points that identify the relative positioning of the different elements associated with each toll agency’s infrastructure. For example, the dataset could be stored as a relational database comprising multiple tables that, in some instances, reference overlapping data (i.e., if two or more toll agencies have similar or overlapping infrastructure elements). The relational database is configured such that a user or computer system can submit a query against the database and retrieve data about one or more of the toll agencies (e.g., a query for the location of a checkpoint, the length / duration of a tolled road along a route, a toll rate fee at a particular time of day, etc.).

[0086] In some embodiments, the integrated sensor checkpoint map is configured in a data index form, either as a back-end database that can be referenced and queried for subsequent downstream tasks and applications or in a data index form that is visually represented by tables and / or graphs. In such embodiments, a user interface is configured to display the integrated sensor checkpoint map using different identifiers that can be selected. The data index can then be filtered, refined, and / or narrowed based on the different identifiers that have been selected.

[0087] Additionally, or alternatively, the integrated sensor checkpoint map is configured to be displayed to a user in a visual mapping format, with the different toll agency infrastructure elements represented in a relational graphic format and / or where the different infrastructure elements are represented by identifiers overlayed on a geographic map of a region. In this manner, a user and / or a computer system is / are able to access data from a plurality of different toll agencies.

[0088] This data can be used to provide toll transaction data and / or augment other toll transaction data which is then subsequently correlated with telematic data obtained for one or more vehicles. Using the integrated sensor checkpoint map, the system is able to map (i.e., correlate / relate) a predicted or historic trip of a vehicle onto the integrated sensor checkpoint map and identify the portions of the trip that would have incurred toll fees.- Page 15 - Docket No. 3400.408AWO

[0089] Based on the data retrieval, the system is able to predict a toll bill associated with the vehicle’s trip. This predicted toll bill can then be automatically compared against the actual toll bill received from one or more toll agencies (e.g., an electronic format of the bill, as received, and / or as scanned into an electronic record) and which is parsed and saved into the relational database tables. If there are differences between the predicted and actual bill, a customer and / or fleet manager can determine if the differences are errors and begin the dispute process with the toll agency. This is an improvement over conventional systems which do not allow users to access data about multiple toll agencies in a single location / related database while also accessing trip data comprising telematics and toll transactions from one or more toll agencies.

[0090] Overall, system 100 is representative of and / or provides functionality for disclosed embodiments which are beneficially directed to obtaining telematic data for one or more vehicles of a fleet and pairing that telematic data with toll transaction data to perform a variety of downstream tasks. These downstream tasks can be categorized into pre-trip analytics, en route trip analytics, and post-trip analytics.PRE-TRIP ANALYTICS

[0091] Pre-trip analytics refers to correlating future telematic data against predicted toll transaction data, or historic telematic data with predicted toll transaction data. For example, a user may wish to run pre-trip analytics to generate a predicted net toll value for a particular vehicle and trip. The system is able to predict a route based on the start destination and stop destination of the trip, including any designated stops between the start destination and stop destination. The system is able to generate a predicted route using the tolled infrastructure and a predicted route using the non-tolled infrastructure. Additionally, or alternatively, the system is configured to generate a predicted route that includes both tolled and non-tolled infrastructure portions. The system is then configured to generate a predicted toll bill for each of the different tolled, partially tolled, and nontolled routes. The system takes into consideration the vehicle class and vehicle weight to avoid infrastructure routes that are prohibited to different vehicle classes / weights, as well as includes any weigh station or customs stops. The system is also able to predict the timing / location of any refueling stops that will need to be taken during the trip and / or any other types of maintenance stops. The system may also include rest stops for the driver based on evaluating the safety of the driver and the length of shifts.

[0092] Along with the predicted route for the trip, the system is configured to generate a predicted total time, including interval time between designated stops, which is- Page 16 - Docket No. 3400.408AWOassociated with the trip. The system is configured to include any predicted delays due to traffic (e.g., accidents, increased volume of cars, and / or construction) and / or inclement weather. The system is also configured to generate predicted fuel costs and an amount of wear and tear on the vehicle (e.g., tire tread, mechanical wear, mileage added, etc.). In some instances, the amount of wear and tear is calculated as a percentage of the total lifetime of the vehicle and / or a monetary amount and / or depreciation of vehicle value. Thus, the system is able to calculate a cost (e.g., time and / or money cost). In some instances, the system is configured to include cost-benefit for deliveries made on time and / or an increase in deliveries made. Additionally, the system is configured to include a cost penalty for deliveries made late on the trip and / or a decrease in the number of deliveries.

[0093] The system is configured to generate the predicted toll bill based on one or more different methods. In some instances, the predicted toll bill is based on historic toll transaction data that has been recorded based on one or more toll bills received for the vehicle on the same or similar trip as the predicted route (e.g., same, or similar start destination and stop destination and / or designated intermediary stops) in the past. The toll bill(s) could also be retrieved and analyzed for a different, but similar vehicle on the same or similar trip.

[0094] Additionally, or alternatively, the predicted toll bill is generated based on the integrated toll agency sensor checkpoint database which comprises toll checkpoints and toll rates for one or more different toll agencies. The toll bill is also configured to be generated from information obtained from a particular toll agency using the toll agency’s API or other data retrieval method. In some instances, the system is configured to perform a check to ensure it has the most up-to-date information stored, wherein if it determines that the information is out-of-date, the system is configured to obtain updated toll agency information. Furthermore, in some instances, the data received by the system is normalized according to the ETL process prior to being analyzed.

[0095] After accessing the toll agency data, the system is able to determine which toll checkpoints (or tolled distances) the vehicle would pass through during the predicted route and calculate the predicted toll bill based on the toll rates corresponding to the toll checkpoints or tolled distances, taking into consideration any variable toll rate schedules based on the vehicle class, vehicle weight, and / or time of day or year. Thus, the system is able to generate a predicted toll bill for each of the different predicted routes for the trip.- Page 17 - Docket No. 3400.408AWO

[0096] In some instances, the system is configured to receive user input defining one or more optimization parameters or metrics by which to determine which predicted route should be suggested to the user. Some example optimization parameters include minimizing time, minimizing cost (e.g., based on gas costs, toll costs, etc.), minimizing wear and tear, and so forth. Thus, in such instances, the system is configured to return the predicted route that provides the greatest optimization for one or more of the user-selected parameters. Alternatively, the system is configured to generate an alert or rating associated with each predicted route based on which parameter is best optimized by each predicted route.

[0097] Furthermore, by correlating the telematic data (in this case predicted telematic data) with the toll transaction data (either historical or predicted), the system is able to evaluate a net toll value for the trip. Additionally, the system is configured to evaluate a net toll value for a set of trips associated with a particular vehicle and / or a set of trips associated with a vehicle fleet using the methods described herein. Fleet administrators are then able to determine which tolls are worth the toll fees in terms of overall operational benefits and which tolls do not provide a positive net value.PRE- VIOLATIONS

[0098] Because the disclosed embodiments are directed to systems and methods that are able to use telematics data along with the toll transaction data, a fleet management company using an improved fleet management system, such as fleet management system 100, will be able to predict if any violations might have been incurred in previous routes and reach out to their customers to see if any vehicle-based violations were received. In this manner, the fleet management company is able to obtain violations early on for analysis and resolution, without having violations stack up over time. Additionally, system 100 is able to analyze previous violations and predict if future violations (e.g., previolations 110) will be incurred and suggest preventive steps that a customer can take in order to mitigate the circumstances causing the violation, which would, in turn, reduce the number of future violations. This helps prevent violations from stacking up over time, especially if it is the same source causing the violation.

[0099] In one example, a truck may be equipped with a transponder that has become faulty such that it no longer is able to be read by the various sensor checkpoints of the tolled route. In some cases, the driver would not be able to know that the transponder is not being read and could go on for days or weeks driving the tolled routes without realizing that the transponder is not working. In such cases, the tolling agency would issue a- Page 18 - Docket No. 3400.408AWOviolation for each time the driver passed through a sensor checkpoint when the transponder would not read because the tolling agency would not know that there is a correctly registered and installed transponder inside the driver’s vehicle. Thus, the tolling agency would have to issue many violations over time for each instance the transponder did not read. However, by comparing the toll transaction data, and any initial violations, against the telematics data of the driver / vehicle, users are able to identify early on which circumstances are causing the violation. In the faulty transponder example, the user could be alerted to the violation of the unread transponder, investigate the transponder, and replace or fix the transponder within a short period of time of receiving the first violation. In this manner, users are able to prevent future violations from occurring from the same or related source of the initial violation.EN ROUTE TRIP ANALYTICS

[0100] After a driver has commenced a trip, the system is configured to dynamically update route analytics and suggestions based on new or changing information. In this manner, the system is configured to correlate toll transaction data with updated route data and / or new toll transaction data with updated route data. For example, the system is configured to suggest a re-routing of one or more vehicles based on weather, traffic, new toll fee data, notification of a violation, warning of a pre -violation, or other factors disclosed about pre-trip analytics. For example, if new toll fee data is retrieved that would produce a negative net toll value, the system is configured to re-route the vehicle such that the net toll value is less negative, neutral, and / or positive. In some instances, if the system detects a previous violation and / or predicts a pre-violation, the system is configured to identify the source of the violation and / or prompt the driver or fleet manager to investigate different possible sources of the violation. If the source cannot be fixed in order to stop the violations (e.g., fix or replace a broken transponder), the system is configured to route the vehicle(s) such that no further violations are incurred (e.g., in the case of a broken transponder, avoiding tolled roads).POST-TRIP ANALYTICS

[0101] After a single trip or a series of trips for a particle vehicle, or a history of trips for a vehicle fleet, the system is configured to perform various post-trip analytics. For example, the system is configured to generate a correlated dataset of historic telematic data and toll transaction data. Based on this correlation, the system is able to identify and manage violations, predict pre-violations, identify discrepancies, determine errors, prepare, manage, and file disputes based on bill errors, as well as manage tag distribution.- Page 19 - Docket No. 3400.408AWOThe system is also configured to generate a report on the net toll value for a vehicle, fleet, or across multiple fleets.LINKING MULTIPLE LEGS OF A TRIP

[0102] In some instances, certain sets of telematic data may need to be correlated and combined prior to comparing and correlating with toll transaction data. For example, some systems may identify multiple trips or trip routes within a set of telematic data received by the computing system. The set of telematic data is then divided into multiple subsets of telematic data, each subset corresponding to a particular trip. However, in some instances, when the subset of the telematic data is correlated to the toll transaction data, the correlated trip dataset may be missing an entry or exit toll transaction data point. This can occur if a driver has stopped on a trip route but has not exited the toll road.

[0103] For example, many toll roads are of such lengths that drivers are required to take mandatory breaks by law or, alternatively, may elect to take a break. However, sometimes these breaks can be an overnight stay some distance off the toll road. The system, based on either a timed-out logic step for non-movement of the vehicle, detected using the telematic tracking system of the vehicle, or mismatched timestamps (i.e., where trips usually occur on the same day, some trips may automatically be ended within the system if a driver stops driving one day and then begins driving the next day).

[0104] In order to solve this problem of truncated telematic datasets, systems are configured to identify different subsets of telematic data that correspond to the same trip, for purposes of correlating to toll transaction data. For example, while a vehicle may not be moving for a prolonged period of time, systems are able to identify that the vehicle stayed within a predetermined range of the toll road and continue to collect the telematic data for the same trip designation. Systems are also configured to access toll road maps and can identify whether there was an exit from the toll road available prior to the previously expected / recorded toll booth exit.

[0105] Once one or more telematic datasets are linked together to represent a complete trip, the combined telematic dataset can then be used by the system to identify the correlating toll transaction dataset. Additionally, by providing a complete telematic dataset for a particular trip, systems are able to predict the toll bill more accurately for the particular trip. Such functionality further aids the system in identifying errors between the predicted toll bill and the actual toll transactions. In some instances, the telematic datasets are combined after having been correlated to different toll transaction data points. In such- Page 20 - Docket No. 3400.408AWOinstances, systems are able to identify correlated datasets that do not have corresponding entry and exit toll transactions.

[0106] A further benefit of predicting toll bills based on telematic data is the increased efficiency in customers being able to submit reimbursement requests to companies. For example, in some instances, customers are able to be reimbursed for certain trip costs, including toll bills. Companies with such policies typically require customers to submit reimbursement requests within a certain time frame. However, by the time customers receive the toll bills, the deadline for reimbursement requests has typically already passed. Thus, by providing the embodiments described herein, the user experience is improved by providing improved and faster access to the toll transaction data for their trips. For example, customers can access their telematic data, along with the predicted toll bill, for their different trips. Systems are configured, in some instances, to automatically generate a reimbursement request form using the telematic data and predicted toll bill information.VIOLATIONS

[0107] In the case of violations, violations 114 are sent to the fleet management support and operations 118. Additionally, or alternatively, some violations (e.g., violations 114) are associated with individual vehicles and are sent to the owner of record of the vehicle. In such cases, the toll agency company may send the violations (e.g., the customer received violations 128) directly to the customer, bypassing the customer’s hired fleet management company. Oftentimes, these violations stack up over time, at which point the company may send the fleet management company months’ worth of violations. It is highly inefficient to go through and dispute any individual violation and so customers are typically left with trying to negotiate a reduced lump sum of money in order to take care of the violation history. In order to mitigate this situation, the fleet management system 100 is configured to allow customers 122 to send customer-received violations 126 to fleet management services 130 via the customer portal 132.

[0108] In this manner, customers 122 are able to upload information about their customer-received violations 126 so that these violations can be added to the violations database 154 which comprises violations that have been sent to the customer and / or to the fleet manager. Thus, system 100 is configured to store and access a combined list of violations. This is an improvement over conventional violation management processes in that system 100 is able to access and analyze a complete record of violations. System 100 is better able to analyze violations for accuracy (e.g., whether the violation was improperly cited or not), identify duplicate violations, consolidate violations for lump-sum- Page 21 - Docket No. 3400.408AWOnegotiating, prevent customers and fleet managers from missing violations, and use the violations to identify pre-violations (i.e., predict future violations). Furthermore, the gathered telematic data is able to identify errors in violations, as well as provide evidentiary support to present to the toll agency for why the violations are erroneous.DISPUTES

[0109] Toll agencies typically only send the total toll bill for a particular time period and vehicle or fleet of vehicles. Similarly, violation bills typically only state the fees owed for one or more violations. Because of this, it is very difficult for customers, or their fleet managers, to identify errors in the toll bills or violations. However, disclosed embodiments provide for methods and systems that are configured to collect telemetric data for one or more vehicles in the customer’s vehicle fleet and compare that telemetric data against the toll bill. Based on the telemetric data, the system is able to predict what the toll bill should have been based on the toll route and toll fee schedule. After predicting what the toll bill should have been, the system compares that to the toll bill received from the respective tolling agency.

[0110] If there is a discrepancy between the system’s prediction and the actual toll bill, the system flags the bill, or particular fee line, of the bill. The customer, or fleet manager, is then able to file a dispute with the toll agency. Because of this pairing of telemetric data with toll transaction data, the disclosed embodiments beneficially provide an efficient and accurate way to identify errors in the bills and violations, file disputes (e.g., disputes 116), and provide evidence for why the dispute should be resolved. This is a significant improvement over conventional fleet management systems which only provide the toll bill information without an efficient and accurate way to identify and investigate errors in the toll bills.ERROR MITIGATION

[0111] There are many different types of errors in bills and violations that the system is able to identify. One bill error that occurs is double billing. For example, at some sensor checkpoints, the checkpoint is equipped with sensors that are configured to record the tag or transponder and sensors that are configured to record the license plate of the vehicle. When a vehicle with the right tag or transponder passes through the sensor checkpoint, one or more sensors should read only the tag or transponder and should not record the license plate (or rather should not charge a toll fee based on the license plate, but only charge a toll fee based on reading the tag / transponder).- Page 22 - Docket No. 3400.408AWO

[0112] However, in some circumstances, the sensor checkpoint malfunctions and records both a toll fee based on the tag and a toll fee based on the license plate. However, the toll bill will often only show the total charges owed. Thus, by comparing the telemetric data against the toll bill information, the system is configured to identify potential double billings. This is especially important when the toll fee associated with the tag is typically represented in the toll bill sent to the customer’ s fleet manager, while the toll fee associated with the license plate is often sent directly to the customer. This is because the license plate is registered to the customer, not to the fleet manager. In such cases, the toll agency would not be able to easily make the connection between the license plate and the fleet manager. This process further compounds the difficulty in identifying double billing. Thus, the disclosed embodiments beneficially provide systems and methods for identifying errors in the bills, such as double-billing, wherein the customer or customer’s fleet manager is able to file a dispute based on the identified error using the paired telemetric-toll transaction dataset.

[0113] In some instances, drivers are transporting multiple-linked vehicles, such as a truck hauling one or more trailers. In such instances, the trailer may separately incur toll bills from the truck, leading to incorrect double billing. For example, a truck may have a transponder that is read at the toll booth, while the trailer may have a license plate that is also read at the toll booth. One additional complication is that the timestamp for each of the truck and the trailer toll bills may not be an exact match since the trailer will be passing through the toll booth slightly later than the truck (where the transponder resides). Systems and methods provided herein facilitate a way to identify incorrect double billing for multiple-linked vehicles. For example, in some instances, the truck and the trailer are each equipped with a telematics tracking system. In such instances, the telematic data for the truck and the telematic data for the trailer can be correlated with each other. In this manner, systems can determine that the truck and trailer are linked and trigger an alert in the system if multiple bills are detected for that multiple-linked vehicle.

[0114] In another example, only the truck may be equipped with a telematic tracking system. Thus, in order to correlate data from the truck to a particular trailer, systems access a look-up table with trailer license plate information, and which truck the trailer was assigned to during a particular trip. In this manner, systems can check to see if the truck’s transponder incurred a toll bill, as well as whether the trailer’s license plate also incurred a toll bill. Customers can then dispute this double billing. This look-up table can either be created / generated by a truck driver who inputs the trailer license plate information into the- Page 23 - Docket No. 3400.408AWOlook-up table at some point during his or her drive. Alternatively, systems are configured to access a third-party database (e.g., through an API to the third-party site) associated with the trailer owner / manager and identify which trailers have been assigned to which trucks. In some instances, the assignment is detected based on a shared trip date, a shared starting and / or ending location, or an explicitly recorded assignment.TAGS / TAG PROCUREMENT

[0115] Each toll agency 104 manages a system and infrastructure of tolled roads / highways and a network of toll sensor checkpoints. At these checkpoints, the toll sensors read the tag or transponder installed on a vehicle or read the license plate, when there is not a readable tag. Each vehicle in a vehicle fleet is equipped with a particular tag (e.g., tags 112) from a toll agency. The toll agency typically has a headquarters in the state from which the tags are based. Additionally, each toll agency has a different fee structure based on the number of tags ordered and used within a fleet. For example, typically, the more vehicles (and thus tags) in a vehicle fleet, some toll agencies provide a better discount rate on the set of tags.

[0116] The telemetric data collected for the vehicle fleet will show the routes for each vehicle in the fleet. Based on the telemetric data and the tag fee structure associated with different tag regions, the system 100 is configured to optimize tag procurement and assignment in order to maximize savings for a particular customer, or across a set of customers.

[0117] For example, the fleet manager may manage multiple fleets for different customers. In this case, the system can determine what the best originating state is for the set of vehicles across multiple fleets. In this manner, the system maximizes the discount based on the number of tags across multiple fleets, wherein each customer is reaping the benefit of lower tag fees because, in effect, their fleet has been “combined” with one or more additional fleets. The system is also configured to determine how to split up the set of vehicles comprising vehicles from multiple fleets in order to best maximize the cost savings. Thus, the disclosed embodiments are beneficially directed to systems and methods that are configured to predict / suggest which set of tags to use, from which originating state to buy the tags, and which vehicles should be assigned which tags in order to maximize monetary savings.

[0118] Attention will now be directed to Fig. 3, which illustrates a computing environment comprising computing systems that include and / or that may be used to implement aspects of the claimed invention. As shown, the computing environment 300- Page 24 - Docket No. 3400.408AWOincludes an application computing system 310 in communication with at least one remote system 320 through network 340. The network 340 may include any combination of wired and wireless connections. Each of the application computing system 310 and / or the remote computing system 320 may be stand-alone devices. They may also each comprise distributed computing systems with any of the computing components described in reference to the computing systems being distributed among two or more separate computers or computing systems, whether locally or remotely located from each other.

[0119] Each of the computing systems also includes one or more hardware processor(s), user interface(s), I / O devices, and hardware storage device(s). Computing system 310 is shown to include includes processors 312, user interfaces 314, I / O devices 316, and hardware storage devices 350, while remote system is shown to include processors 322, user interfaces 324 and VO devices 326, and hardware storage devices 330. The hardware storage devices (350, 330) store computer-executable instructions that are executable by the corresponding hardware processor(s) to implement the disclosed methods and functionality described herein.

[0120] For example, computer-executable instructions are stored that are configured to cause the computing system(s) to generate correlated trip datasets comprising normalized toll transaction data and normalized telematic data, as well as generate a net present toll value configured to indicate whether the tolled route, along with its associated toll fees, is worth the time saved by taking the tolled route. This net present toll value can then be compared against a net present toll value threshold, wherein the system determines whether the net present toll value meets or exceeds a net present toll value threshold. If the net present toll value meets or exceeds the net present toll value threshold, the system is configured to generate a recommendation to continue using the various tolls. However, if the net present toll value does not at least meet the net present toll value threshold, the system is configured to generate a recommendation to discontinue the use of one or more tolls that had been previously used.

[0121] By configuring the system in this manner, the system is able to improve the user experience by identifying specific tolls or a plurality of tolls that are worthwhile to a customer vs. those tolls that are not beneficial to a customer based on one or more different criteria (e.g., criteria such as time savings, monetary savings, driver safety, vehicle wear, and tear, etc.). Thus, in some instances, the net present toll value is a net present value of time, where the system optimizes the routes based on the greatest reduction in time and- Page 25 - Docket No. 3400.408AWOidentifies which tolls or tolled portions of the route will lead to the greatest reduction in time.

[0122] The computing system(s) is / are further configured to determine whether one or more vehicle tags should be reassigned based on monetary savings and reassign one or more vehicle tags as part of vehicle tag procurement and management. The system(s) is also configured to generate one or more error alerts when the system finds discrepancies and errors in the toll transaction data based on comparing the toll transaction data to the telematics data. The computing system(s) is further configured to identify abuse and fraud in vehicle fleets.

[0123] The referenced user interfaces may include application interfaces and / or user portals (e.g. 318, 328) that receive user input (e.g., search queries, trip preferences, activity information, user profile information, etc.) that is entered at an I / O device (e.g., keyboard, mouse, touch screen, microphone, etc.) and that present / display or otherwise render information, such as toll transaction data, fleet data, and / or telematic data, to a user on a computer display screen or other I / O device (e.g., phone screen, speaker, haptic feedback device, headset display, etc.).

[0124] The user interfaces are configured to display a plurality of selectable icons within the display of the user interface. As a note to the use of “icon” herein, it should be appreciated that icon refers to a visual representation of an interface item that is configured to be selectively operational, such that whenever the icon is selected, it is configured to cause a particular function within the application (e.g., displaying a new application page and / or generating an integrated toll agency information database).USER PORTAL INTERFACE(S)

[0125] Attention will now be directed to Fig. 4A, which illustrates an example user interface, or user portal 400, which is configured to provide a user with trip information, analytics reports, and other fleet management tools. It should be appreciated that user portal 400 is representative of various user portals, including a fleet manager portal, an administrator portal, a customer portal, and / or a driver portal.

[0126] For example, user portal 400 is configured to allow a user to select a particular trip from a plurality of historical and planned trips (e.g., trip 402). The trip 402, in this illustration, is a historical trip (i.e., a trip that has been completed). Trip 402 is associated with a planned route 404, which was the route initially projected for the trip, as well as the recorded route 406 which is the GPS data for the actual route taken by a particular vehicle for that trip. Trip 402 is also associated with a predicted toll bill 408, which is the toll bill- Page 26 - Docket No. 3400.408AWOthat was initially projected for the trip based on the planned route 404. Additionally, or alternatively, the predicted toll bill 408 is based on the recorded route 406. The user is also able to access the actual toll bill (e.g., toll bill 410) once it has been generated and transmitted by the toll agency. The user is also able to access any violations 412 which have been received in conjunction with the illustrated trip (e.g., trip 402).

[0127] After analyzing and comparing the different datasets (e.g., predicted toll bill 408 against the actual toll bill 410), the system determines whether there are any differences or discrepancies between the two toll bills. If there are no discrepancies, the system prompts the user to pay the toll bill. If there are discrepancies, the system (e.g., system 100) further analyzes the toll bills, as well as the route data, in order to determine if the discrepancies are errors made by the toll agency. If the errors are determined to be or predicted to be actual errors (e.g., errors 414), the user is directed to a dispute management system (e.g., disputes 416). The dispute management system allows a user to track disputes, including receiving suggested disputes 418 (i.e., disputes on errors identified by the system that the user should file), filed disputes 420 (i.e., disputes that have been filed with the toll agency), and resolved disputes 422 (i.e., disputes that have been resolved). Disputes can be resolved in different ways, including determining that the discrepancy was based on faulty data and thus should be amended in toll bill 410 or determining that the discrepancy was not an error in the toll bill 410 and the toll bill 410 should not be amended.

[0128] When a user selects a particular trip, it is displayed in various manners. For example, in some instances, the user portal 400 is configured to display the trip information on a map interface 480. The map interface 480 is generated based on the integrated toll sensor checkpoint dataset, as well as the recorded route 406 which is visually represented by a continuous route line 484. Map interface 480 is also configured to indicate what weather conditions were like, timestamps along the route, any delays incurred, traffic conditions, maintenance performed, vehicle / cargo inspections, weigh stations, etc. Additionally, or alternatively, the user portal 400 is configured to display the trip information in a list format (e.g., toll data 424). The toll data 424 shows a list of toll record entries which each correspond to a particular sensor checkpoint on the map.

[0129] For example, toll record 426 corresponds to sensor checkpoint 486, toll record 428 corresponds to sensor checkpoint 488, toll record 430 corresponds to sensor checkpoint 490, toll record 432 corresponds to sensor checkpoint 492, toll record 434 corresponds to sensor checkpoint 494, and toll record 438 corresponds to sensor- Page 27 - Docket No. 3400.408AWOcheckpoint 496. The user portal 400 also displays additional information such as driver information 440 and vehicle information 442.

[0130] The user portal 400 is also configured to display potential or confirmed errors in the toll data 424 in a flagged format (e.g., bolding in toll record 436). In this case, toll record 436 corresponds to sensor checkpoint 494, in addition to toll record 434. The system identified this error, which is a double-billing error. This would result in a suggested dispute 418 being generated which can be reviewed and approved / denied by the user prior to filing and / or prior to a dispute being automatically filed. In some embodiments, a dispute notification is automatically generated and transmitted to the billing and tolling agency in response to detecting a single error or a pre-determined number of errors (e.g., two-ten errors, or more than ten errors). In some instances, the dispute notification comprises an electronic record. In other instances, the dispute notification comprises a physical letter. The dispute notification will, in some instances, include evidence that identifies the error in the bill and / or violation, in some instances, the client and / or administrator is / are notified whenever a dispute notification is generated and / or prior to transmitting the dispute notification. It should be appreciated that the automatically filed dispute will be tailored to the individual tolling agency dispute resolution processes.

[0131] Attention will now be directed to Fig. 4B, which illustrates a user interface displaying a correlated dataset 443. For example, a set of toll data 444 (e.g., toll transaction data) has been correlated to a set of telematic data (e.g., telematic data 458). Toll data 444 comprises a plurality of toll transaction data points or toll records (e.g., toll record 446, toll record 448, toll record 450, toll record 452, toll record 454, and toll record 456). Telematic data 458 comprises a plurality of telematic data points or telematic records (e.g., telematic record 460, telematic record 462, telematic record 464, telematic record 466, telematic record 468, and telematic record 470).

[0132] Using systems and methods described herein, different data points in the toll data 444 and the telematic data 458 have been correlated to each other. For example, toll record 446 is correlated to telematic record 460, toll record 448 is correlated to telematic record 462, toll record 452 is correlated to telematic record 464, toll record 454 is correlated to telematic record 466, and toll record 456 is correlated to telematic record 468.

[0133] In some, not all data points from either dataset are found to be correlated. For example, toll record 450 does not have a corresponding data point in the telematic data 458. Similarly, telematic record 470 does not have a corresponding data point in the toll- Page 28 - Docket No. 3400.408AWOdata 444. Such discrepancies between the datasets allow the system to identify possible errors in either dataset or alert a system user (e.g., fleet manager) for further investigation.

[0134] Additionally, each of the correlated data point pairs may be associated with a particular confidence rating. For example, each data point comprises a set of characteristics. If the toll data point is determined to share a certain number of characteristics that meets or exceeds a confidence threshold, the data points are determined to be correlated (e.g., a correlation link is generated for the data point pair). However, if the confidence threshold is not met, the system generates an alert that while some characteristics are shared between the data points, some characteristics are not shared. For example, the timestamp might match but the geographic location might not match. This is another example of the system being able to identify errors in the data and alert a system user.

[0135] Attention will now be directed to Fig. 4C, which illustrates a user interface displaying a correlated trip dataset. Using the correlated dataset 443 described in Fig. 4B, systems are able to identify a subset of the toll data points and a subset of the telematic data points that correspond to the same trip. The system is then able to generate a correlated trip dataset specifically for that trip. For example, correlated trip dataset 445 comprises toll data 444 and telematic data 458. However, toll data 444 comprises toll record 446, toll record 448, toll record 450, and toll record 452. Telematic data 458 comprises telematic record 460, telematic record 462, and telematic record 464.

[0136] It should be appreciated that some user interfaces are configured to format records to alert a user that a potential error has been detected. For example, toll record 450 does not have a corresponding telematics record and so the user interface has been updated to display toll record 450 in different formatting (e.g., bolding, italics, underlining) than the other corresponding record pairs (e.g., regular typeface).

[0137] Attention will now be directed to Fig. 5, which illustrates various examples of discrepancies 502 and errors 504 that the system is configured to identify. For example, the system may find route discrepancies 506, fee discrepancies 508, or other discrepancies 510. The route discrepancies 506 may be differences between the planned route and the recorded route. The fee discrepancies 508 may be differences between the predicted toll bill and the actual toll bill or between the toll transaction data and the violations. These differences are analyzed, and the system predicts a source of the difference, whether the difference is due to the system’s own analytics or source data, or whether the difference is due to an error made by the toll agency. If the difference is due to the system’s analytics,- Page 29 - Docket No. 3400.408AWOthen the system is configured to perform self-analysis to determine where the system should be updated in order to mirror the accurate toll transaction data. For example, the system may have obtained the wrong or outdated fee schedule (e.g., error 518), wherein the fee schedule for that toll agency will be updated with the correct fee schedule in order to improve the toll bill prediction.

[0138] However, if the difference is due to an error made by the toll agency, the system flags the discrepancy as an error and determines what type of error has been made. Some examples of errors 504 include double-billing 512, an extra sensor recording 514 (i.e., at a checkpoint that was not passed through by the vehicle in question), and a missing sensor recording 516.

[0139] Attention will now be directed to Fig. 6, which illustrates various example embodiments of user portals 602. For example, if the user portal is configured as an admin portal 604, the portal is configured to allow a user to access various fleet management tools such as flagged trips 606, toll transaction data 608, violations 610, tag procurement 612, error resolution 614, and value analytics 616. If the user portal is configured as a customer portal 617, the portal is configured to allow a user to access flagged trips 618, error resolution 620, fraud prevention 622, toll transaction data 624, violations 626, and value analytics 628. In addition, if the portal is configured as a driver portal 630, the portal is configured to allow a user to access and update information about flagged trips 632 that have been flagged for the driver, route suggestions 636 (prior to leaving and en route of the trip), violation prevention 634 (i.e., trouble-shooting suggestions to avoid additional or new violations), and fraud prevention 638 (i.e., alerting the driver to possible theft or loss of a transponder, or another issue). If the portal is configured as a toll authority portal 640, the portal is configured to allow a user to access and update information for facilitating improved processes for sending toll bills and collecting bill payments. For example, toll authority users are provided access to transponder tolls 642 and vehicle tolls 644. Toll authority portals 640 may also comprise access to toll fee schedules, geographic information for different toll booths and toll roads, customer databases, and toll pass information, among others. Toll authority portal 640, in some instances, is also configured to display one or more different selectable icons which are operable when selected to cause the computing system to automatically generate and transmit toll bill invoices to the respective toll infrastructure users.

[0140] Such user interfaces as illustrated in Fig. 6 beneficially provide improved access, navigation, filtration, and use of the different datasets, including correlated datasets- Page 30 - Docket No. 3400.408AWOof telematic and toll transaction data. In some instances, systems are configured to track the historical activity of which portal functions are most used by a user and automatically reconfigure the user’s portal to display the information and selectable icons which the user has interacted with based on increasing use or frequent use exceeding a predetermined use threshold.

[0141] Attention will now be directed to Figs. 7A-7D and Figs. 8A-8F, which illustrate example embodiments of flow diagrams and corresponding user interfaces configured for generating a database comprising toll agency data, including toll agency sensor checkpoints.

[0142] As shown, for example, a backend administrator is able to identify (701) a new agency, including the name, state, and website associated with the newly identified toll agency. Users are provided user interfaces through which they can add a new agency, wherein the new agency is saved in the database (DB), as shown by “add agency in UI and local DB” 702 shown in Fig. 7A). An example of a user interface that can be used to add a new agency is shown in Fig. 8A. The system (either through automatic machine processes or user processes) obtains (705) toll facility information, including roads, bridges, and tunnels, as well as (707) toll pricing based on vehicle types, classes, and plaza types (708). Rate classes are added, for example, as shown by add / change vehicle classification 706, including other diagram components, shown in Fig. 7A. User interfaces for adding and editing rate classes are shown, for example, in Fig. 8C. After installing (710) and starting (712) the system program, a user interface associated with the system program is configured to allow a user to add a new toll road authority (TRA) to be stored in the database, as illustrated by step 704 in Fig. 7B. Examples of user interfaces for adding and editing TRAs are shown in Figs. 8B, 8E, and 8F. Next, the interface is configured to allow a user to add or change (706) vehicle classifications for toll rates.

[0143] Referring to Fig. 7C, the user interface is further configured to allow a user to add / change 720 transportation department associations (TDAs) or government-related transportation organizations, including the location using numerical input 721 and / or map input 722, add / change the TDA radius for a nearby area 723, add / change TDA radius for a far area 724, and set / change the TDA type (e.g., barrier or distance) 725. For example, some tolls are calculated based on passing through a particular barrier, where each barrier (i.e., sensor checkpoint) is assigned a particular toll fee. Additionally, or alternatively, some tolls are calculated based on the distance driven on a tolled route. Similar user- Page 31 - Docket No. 3400.408AWOinterfaces that are shown for adding and editing TRAs can also be used to add and / or edit TDAs.

[0144] Once there are no more TDAs or TRAs to add / change, the interface is configured to parse 726 the agency’s data for toll rates based on distance, link 728 the rates with the correct TRAs and rate classes for the toll agency, and prepare 730 datasets to be imported into the database. Referring to Fig. 7D, the interface is also configured to collect information about the barrier type TRAs, wherein the interface is configured to allow a user to select 732 a particular barrier TRA, add / edit 708 the toll rate record of the selected TRA, and edit 734 the following information: rate amount 736 , toll rate type 738, toll rate class 740, and toll rate validity time interval 742. Toll rate records are added and / or edited, for example, as illustrated by “add / edit toll rate record” 708, as shown in Fig. 7D. Examples of user interfaces that are configured to allow a user to add or edit a toll rate is shown in Fig. 8D.

[0145] For example, Fig. 8A illustrates a user prompt 810 for adding a new agency. Fig. 8B illustrates a user prompt 820 for adding a new TRA, including a description, latitude, and longitude. Alternatively, systems can automatically update the latitude and longitude based on a user selection of a pixel of a graphical representation of a geographical map. Fig. 8C illustrates a user prompt 840 for adding in a rate class, including the agency class name, the vehicle type, and other vehicle characteristics.

[0146] Fig. 8D illustrates a user interface 872 comprising a first window that displays a table of a toll fee schedule, including the rate class, toll amount, and starting and ending times for that particular toll amount. A second window is shown which is a user prompt that allows a user to update the table with a new toll rate, including the rate class, toll amount, payment type, and timeframe of the toll amount.

[0147] Fig. 8E illustrates a user interface including a first window 880 for displaying a geographical map and a second window configured as a user prompt to add a new TRA. Fig. 8F illustrates a user interface 890 comprising a first window for adding and viewing information for a particular agency, a second window for displaying and navigating a map, and a third window configured as a user prompt to add a new toll road authority (TRA) to the system database.

[0148] Referring back to Fig. 7D, after the system determines that no other changes are needed for the TRA, the system is configured to run 746 the SQL WB script in order to make the changeset and apply 748 the changeset to the central database. As new toll agencies are discovered, each can be added to the database such that an integrated inter -- Page 32 - Docket No. 3400.408AWOagency sensor checkpoint dataset can be generated. The system is configured to generate a listing or map visualization of the integrated inter-agency sensor checkpoint dataset, such that a user is able to easily access and view the different toll agencies, their respective infrastructure, and corresponding toll rates. In this manner, the system is configured to receive user input and / or computer-retrieved (e.g., through web-page-based text crawling or through APIs) information about a plurality of toll agencies. This data is then used in conjunction with the telematic data of a vehicle in order to estimate / predict a toll bill for a particular trip or set of trips. This predicted toll bill can be compared against the toll bill sent by the toll agency, wherein the system is able to identify discrepancies and determine if the discrepancies are errors that need to be corrected.

[0149] The system is also configured to analyze the predicted toll bill and determine a net present value of taking the tolled routes as compared to the resources (e.g., time) predicted for non-tolled or partially tolled trips. The system analyzes the predicted toll trip vs. the predicted non-tolled trip.

[0150] PROCESS FLOW DIAGRAMS

[0151] Attention will now be directed to Fig. 9, which illustrates a process flow diagram comprising a plurality of acts associated with a method for generating a correlated trip dataset comprising normalized toll transaction data and normalized telematic data. Fig. 9 illustrates a flow diagram that includes various acts (act 910, act 920, act 930, act 940, act 950, act 960, and act 970) associated with exemplary methods that can be implemented by computing system 310.

[0152] As shown in Fig. 9, the first illustrated act is directed to identifying a customer fleet comprising a plurality of vehicles (act 910). The system then identifies a trip taken by a particular vehicle included in the plurality of vehicles (act 920) and accesses toll transaction data received from one or more toll agencies (act 930). The toll transaction data is associated with the particular vehicle included in the plurality of vehicles. The toll transaction data from each toll agency is normalized according to a first pre-determined standard formatting (act 940). In addition to toll transaction data, the systems access telematic data associated with the particular vehicle (act 950). The telematic data including GPS coordinate data associated with a route traveled by the particular vehicle during the trip. The telematic data is normalized according to the second pre-determined standard formatting which corresponds to the first pre-determined standard formatting such that the computing system is configured to identify data points in the toll transaction data that- Page 33 - Docket No. 3400.408AWOcorrelate with data points in the telematic data (act 960). Finally, the systems generate a correlated trip dataset comprising the normalized toll transaction data and the normalized telematic data (act 970).

[0153] It should be appreciated that the datasets are configured to be correlated based on one or more corresponding attributes. In some instances, a trip comprises a plurality of events (e.g., passing through a toll sensor, crossing a toll bridge, traveling a certain portion of a tolled road). Similarly, a toll bill is based on one or more events that incurred a toll fee or violation. Thus, a data point in the toll transaction data and a data point in the telematic data correlate to each other based on the data points corresponding to a similar or the same event and / or portion of the route traveled by the particular vehicle during the trip.

[0154] In some instances, the datasets are correlated based on shared events, as described above, based on matching timestamps, based on matching GPS coordinate locations, based on matching time durations, based on matching distance durations, and / or another attribute that is shared between the toll transaction data and the telematic data. The event could comprise any data communication between the vehicle (e.g., transponder) and toll agency infrastructure, between the vehicle (e.g., GPS tracker) and fleet management system, and / or between the toll agency and the fleet management system.

[0155] Thus, by correlating the datasets, a system and / or user is able to cross-reference between the two datasets and identify any differences that may be errors in the toll transaction data. This correlated dataset can be stored as a relational database that is searchable through a user interface or is able to be queried by a user and / or computing system. The correlated dataset can be visually referenced and / or can be indexed and then referenced via a query.

[0156] Additionally, the correlated trip dataset is configured to be presented to the user in an interactable table format and / or interactable map format. This correlated trip dataset, in any of its forms, is able to be referenced for downstream analysis and tasks (e.g., bill error analysis, violation analysis, tag management, etc.).

[0157] Attention will now be directed to Fig. 10, which illustrates a process flow diagram comprising a plurality of acts associated with a method for generating a net present toll value. Fig. 10 illustrates a flow diagram that includes various acts (act 1010, act 1020, act 1030, act 1040, and act 1050) associated with exemplary methods that can be implemented by computing system 310. As shown in Fig. 10, the first illustrated act is directed to identifying a customer fleet comprising a plurality of vehicles (act 1010). The- Page 34 - Docket No. 3400.408AWOsystems are then configured to access toll transaction data about the plurality of vehicles (act 1020) and access telematic data associated with the same plurality of vehicles (act 1030). The telematic data includes a first set of GPS coordinate data associated with tolled routes traveled by the plurality of vehicles and a second set of GPS coordinate data associated with non-tolled routes traveled by the plurality of vehicles. Based on comparing a first set of GPS coordinate data and the second set of GPS coordinate data, the systems then calculate at least a value difference between a tolled route and a non-tolled route (act 1040) and generate a net present toll value. In some instances, the system is further configured to indicate whether the tolled route, along with its associated toll fees, meets a net present toll value threshold (act 1050).

[0158] In some instances, the value difference is based on a difference calculated between one or more attributes of the tolled route vs. the non-tolled route. For example, the value difference is configurable as a time difference, wherein a first time is determined for the tolled route and a second time is determined for the non-tolled route. In such examples, the net present toll value is a net present value of time based on the time difference calculated for the different routes.

[0159] Attention will now be directed to Fig. 11, which illustrates a process flow diagram comprising a plurality of acts associated with a method for generating a net present toll value. Fig. 11 illustrates a flow diagram that includes various acts (act 1110, act 1120, act 1130, act 1140, act 1150, act 1160, act 1170, act 1180, act 1190, and act 1195) associated with exemplary methods that can be implemented by computing system 310. As shown in Fig. 11, the first six illustrated acts (act 1110, act 1120, act 1130, act 1140, act 1150, and act 1160) are directed to similar acts as shown in Fig. 9 (e.g., act 910, act 930, act 940, act 950, act 960, and act 970).

[0160] After generating the correlated trip dataset comprising the toll transaction data and the telematic data, the system is configured to access tag fee data from different toll agencies (act 1170) and access a set of assigned vehicle tags associated with one or more customer fleets (act 1180). The system then determines whether one or more vehicle tags should be reassigned in order to maximize monetary savings according to the tag fee data from each toll agency by comparing the correlated trip dataset against the tag fee data (act 1190). In response to determining that one or more vehicle tags should be reassigned, the system is configured to reassign one or more vehicle tags and update the set of assigned vehicle tags based on the reassignment of the vehicle tags (act 1195).- Page 35 - Docket No. 3400.408AWO

[0161] In some instances, license plates and license plate registrations are also used with agencies that do not have transponders. Additionally, or alternatively, license plates are used as a backup identifier for vehicles that use transponders, in the case that the transponders are broken or unavailable. Thus, in some circumstances, the tag fee data is based on transponder data, based on license plate data, or a combination of both.

[0162] In some instances, the monetary savings are based on identifying tag discounts associated with a particular tag distribution. Additionally, or alternatively, the monetary savings are further based on identifying transponder fees associated with the one or more customer fleets, such that the system is configured to compare monetary savings obtained from leveraging tag discounts against transponder fees incurred from utilizing transponders in the one or more customer fleets. For example, some agencies charge fees for the different tags and associated distribution of those tags, while some agencies have additional charges for using transponders vs. license plates for toll transaction tracking / reading. Thus, the system is able to determine net monetary savings by taking into consideration any discounts achieved by changing the tag distribution while also taking into consideration any fees incurred from using transponders and / or license plates.

[0163] Attention will now be directed to Fig. 12, which illustrates a process flow diagram comprising a plurality of acts associated with a method for identifying errors in toll transaction data. Fig. 12 illustrates a flow diagram that includes various acts (act 1210, act 1220, act 1230, act 1240, act 1250, act 1260, act 1270, and act 1280) associated with exemplary methods that can be implemented by computing system 310. As shown in Fig. 12, the first six illustrated acts (act 1210, act 1220, act 1230, act 1240, act 1250, and act 1260) are directed to similar acts as shown in Fig. 9 (e.g., act 910, act 920, act 930, act 940, act 950, and act 960).

[0164] The system is further configured to identify one or more discrepancies between the normalized toll transaction data and the normalized telematic data (act 1270) and generate one or more error alerts corresponding to the one or more discrepancies (act 1280). One or more error alerts are configured to be presented to a user. In some instances, this includes sending the alert to an administrator and / or end user associated with the fleet / vehicle(s).

[0165] Attention will now be directed to Fig. 13, which illustrates a process flow diagram comprising a plurality of acts associated with a method for detecting abuse and fraud in vehicle fleet management. Fig. 13 illustrates a flow diagram that includes various- Page 36 - Docket No. 3400.408AWOacts (act 1310, act 1320, act 1330, act 1340, act 1350, act 1360, act 1370, and act 1380) associated with exemplary methods that can be implemented by computing system 310. As shown in Fig. 13, several acts (act 1310, act 1320, act 1340, and act 1350) are directed to similar acts as shown in Fig. 9 (e.g., act 910, act 920, act 950, and act 960). Additionally, as shown in Fig. 13, the system is further configured to access a planned route associated with the trip that was generated prior to a trip departure (Act 1330). The systems are then configured to identify one or more discrepancies between the planned route and the normalized telematic data (act 1360). If discrepancies are identified, then the system is configured to generate one or more error alerts corresponding to the discrepancies in order to alert a user (act 1370). In some instances, this includes sending the alert to an administrator and / or end user associated with the fleet / vehicle(s).

[0166] For instance, by way of example and not limitation, the disclosure includes embodiments configured for performing fraud, abuse, and violation detection based on detecting discrepancies in toll transaction data as compared to telematics data of a vehicle or fleet. Toll transaction data comprises one or more of: toll fees, toll locations, toll timestamps, toll bills, customer invoices, tag fees, transponder fees, violation records, violation fees, and / or other toll-related data. In general, the disclosed embodiments are configured to notify customers and / or fleet managers of possible issues with their accounts. The system is also configured to make automatic and / or suggest manual configuration changes or transponder changes in response to these detected issues. The disclosed embodiments are also configured for identifying the root causes of these issues, in order to make / suggest changes in the fleet management and operation.

[0167] Disclosed systems and methods are also configured to identify transactions that are not correlated to telematics data. By way of further example, a vehicle may not be moving (according to the telematics data corresponding to the vehicle) but the transponder is still incurring tolls. This could be due to the transponder being placed accidentally in the wrong vehicle and / or due to the transponder being stolen. Theft is a relatively large problem among fleet vehicles. If a transponder was stolen from a vehicle that is not being used very much, there is no way for a customer to know about it unless they are proactively watching the account. Disclosed systems and methods herein facilitate automated fraud detection by watching for the abnormal activity of vehicles and their corresponding transponders / license plates / or other vehicle identifiers.

[0168] Disclosed systems and methods are also configured to correlate toll transaction data to telematics that happen outside of a particular customer’s business rules schema.- Page 37 - Docket No. 3400.408AWOThus, the disclosed embodiments are configured to identify uncharacteristic or misuse of transponders. By way of further example, in some instances, a customer company has a policy that work trucks are not to be used after 6pm. However, if the toll transaction data shows toll fees being incurred after 6pm, the system is configured to identify this behavior and generate a notification of the customer as to the unauthorized toll fee incurrence. A customer / fleet manager is then able to take mitigating steps to ensure that further abuse is not undertaken by company employees.

[0169] By way of further example, disclosed systems and methods are configured to identify violations much earlier than is achieved by conventional systems and methods. Disclosed systems and methods are able to achieve improved violation detection because of the access to real-time telematics data for a vehicle or set of vehicles. Through traditional methods, some violations take days, weeks, or a complete invoice cycle to come to a customer’s attention thereby incurring a significant increase in the number of violations and associated fines. By identifying violations in real-time or near real-time, the system is able to facilitate monetary savings for a customer by alerting the customer and / or fleet manager to the violation. This early-warning notification allows the customer to take mitigating action to prevent future violations and / or prevent late fees on current violations. Additionally, the system is able to determine whether or not the violation is accurate, based on comparing the violation against the telematic data.

[0170] Thus, the disclosed systems and methods are configured for identifying unexpected costs due to violations because the violations will be identified in near -realtime or real-time. By way of further example, in some instances, speed violations at toll booths cause transponders to be suspended. This happens automatically with the only notification being typically sent to the customer via mail. This is very expensive for a commercial fleet because they will now incur a violation for days or weeks until they understand they received a speed violation. To improve these conventional processes and toll-user experience, disclosed systems and methods facilitate improved notifications of such violations. In the case of a speed violation, the system is able to determine whether a speed violation has occurred in real-time or near real-time based on the telematics data that is recorded (e.g., the speed of the vehicle while passing through the toll booth).

[0171] Additionally, given the complex discount and violation structure, which is unique to each agency, the system is able to analyze the invoices for potential violations. For example, if the system is expecting and / or had predicted a toll bill of $10 but received a toll bill for $50, the system is configured to identify the source of the difference. In some- Page 38 - Docket No. 3400.408AWOinstances, the source of the difference is a customer (e.g., driver) behavior, wherein the system is configured to suggest corrections in the customer's behavior. Additionally, or alternatively, the source of the difference is an error in the toll bill, wherein the system is configured to generate a dispute notification to the user and / or automatically file a dispute with the correct tolling agency.

[0172] Attention will now be directed to Fig. 14, which illustrates a process flow diagram comprising a plurality of acts associated with a method for generating a correlated trip dataset comprising toll transaction data and telematic data. Fig. 14 illustrates a flow diagram that includes various acts (act 1410, act 1420, act 1430, act 1440, act 1450, and act 1460) associated with exemplary methods that can be implemented by computing system 310.As shown in Fig. 14, the first illustrated act is directed to accessing a plurality of toll transaction data points incurred by a vehicle transponder associated with a vehicle of a vehicle fleet passing through one or more toll checkpoints (act 1410). In some instances, each toll transaction data point comprises a set of characteristics including a toll fee, a toll timestamp, a toll location, or a combination thereof.

[0173] Systems also receive a plurality of telematic data points from a telematic tracker associated with the vehicle of the vehicle fleet (act 1420). Subsequently, systems compare the plurality of toll transaction data points with the plurality of telematic data points (act 1430). In some instances, each telematic data point comprises a set of characteristics including a telematic timestamp, a telematic location, or a combination thereof.

[0174] Based on comparing the plurality of toll transaction data points and the plurality of telematic data points, systems identify one or more toll transaction data points of the plurality of toll transaction data points that correspond to one or more telematic data points of the plurality of telematic data points, wherein the one or more toll transaction data points corresponds to the one or more telematic data points based on one or more shared characteristics between the one or more toll transaction data points and the one or more telematic data points (act 1440). By implementing systems in this manner, systems are able to analyze the different data points and use characteristics from either plurality of data points in order to find corresponding data points that previously would have been difficult to identify.

[0175] After identifying the corresponding data points, systems generate a plurality of correlation links for the one or more toll transaction data points and the one or- Page 39 - Docket No. 3400.408AWOmore telematic data points, each correlation link being configured to correlate a particular toll transaction data point to a particular telematic data point (act 1450). By generating correlation links, systems are able to use the correlation links to provide improved datasets and improved user interfaces for navigating and filtering those datasets by allowing users to view which data points correspond to each other.

[0176] Finally, systems generate a correlated dataset comprising the plurality of toll transaction data points correlated to the plurality of telematic data points based on the plurality of correlation links (act 1460). By generating a correlated dataset in this manner, systems are able to facilitate many improved downstream applications, such as error identification, dispute resolution, net present toll value determination, as well as improved user interfaces for accessing, navigating, and filtering data.

[0177] This correlated dataset can then be displayed at a user interface that is configured to facilitate improved access and navigation of telematic and toll transaction data. For example, systems display the plurality of toll transaction data points in a first location of a first window of a user interface and display the plurality of telematic data points in a second location of the first window of the user interface. In response to generating the correlated dataset, systems display the correlated dataset by dynamically updating the first window with a plurality of visual indicators associating the one or more toll transaction data points with the one or more telematic data points that correspond to the one or more toll transaction data points, the plurality of visual indicators being graphical representations of the plurality of correlations links.

[0178] Systems can utilize different methods to identify corresponding data points and identify shared characteristics between corresponding data points. For example, in some instances, systems also determine that the particular toll transaction data point correlates to the particular telematic data point based on determining that the toll timestamp of the particular toll transaction data point is similar to the telematic timestamp or that the toll location of the particular toll transaction data point is similar to the telematic data point of the particular telematic data point.

[0179] In some instances, systems normalize the toll transaction data and telematic data prior to additional analysis. For example, in some instances, prior to identifying one or more toll transaction fees that correlate with the one or more time-stamped coordinate data points, systems (i) normalize the set of toll transaction data from each toll agency of the one or more toll agencies according to a first predetermined standard formatting and- Page 40 - Docket No. 3400.408AWO(ii) normalize the set of telematic data to a second predetermined standard formatting that corresponds to the first predetermined standard.

[0180] In some instances, systems are able to identify specific trips or trip routes for a particular vehicle or set of vehicles based on analyzing the telematic data and / or toll transaction data. For example, systems identify a first coordinate location corresponding to the start of a trip route and a second coordinate location corresponding to the end of the trip route traveled by the vehicle and identify a first telematic data point corresponding to the first coordinate location and a second telematic data point corresponding to the second coordinate location.

[0181] Next, systems identify a subset of the plurality of telematic data points comprising the first telematic data point, the second telematic data point, and one or more consecutive telematic data points received from the telematic tracker between the first telematic data point and the second telematic data point. Based on the plurality of correlation links, systems identify a subset of the plurality of toll transaction data points that correspond to the subset of the plurality of telematic data points and generate a correlated trip dataset comprising the subset of the plurality of telematic data points and the subset of the plurality of toll transaction data points for the trip route traveled by the vehicle.

[0182] These correlated trip datasets are beneficially presented and navigable by a user at a user interface. For example, systems display in a second window an illustration of a geographical map. In response to identifying the first coordinate location, systems then dynamically update the second window by displaying a first icon at a first location of the geographical map that corresponds to the first coordinate location. Additionally, in response to identifying the second coordinate location, systems dynamically update the second window by displaying a second icon at a second location of the geographical map that corresponds to the second coordinate location. Finally, in response to identifying the subset of the plurality of telematic data points, systems also dynamically update the second window by displaying one or more additional icons. Each additional icon corresponds to a different consecutive telematic data point of the one or more consecutive telematic data points.

[0183] In some instances, systems further update the user display with toll transaction information. For example, in response to generating the correlated trip dataset, systems dynamically update each icon previously displayed in the second window of the- Page 41 - Docket No. 3400.408AWOuser interface to be further selectable to further display toll transaction information from a corresponding toll transaction data point from the correlated trip dataset.

[0184] In some instances, systems are configured to identify incomplete trips based on incomplete telematic datasets. By identifying incomplete trips, systems are able to identify different portions of the same trip and combine the respective telematic datasets to represent a whole or complete trip. For example, systems identify a subset of the plurality of telematic data points comprising the first telematic data point, the second telematic data point, and one or more consecutive telematic data points received from the telematic tracker between the first telematic data point and the second telematic data point further comprises.

[0185] Systems also identify a first subset of the plurality of telematic data points comprising the first telematic data point but missing the second telematic data point and identify a second subset of the plurality of telematic data points comprising the second telematic data point but missing the first telematic datapoint.

[0186] Systems then determine that the first telematic data point corresponds to the second telematic data point as the start of the trip route and the end of the trip route, respectively. In response to determining that the different subsets of telematic data are portions of the same trip, systems combine the first subset of the plurality of telematic data points and the second subset of the plurality of telematic data points to generate the subset of the plurality of telematic data points such that the subset of the plurality of telematic data points corresponds to a complete trip route.

[0187] Systems and methods provided herein beneficially provide technical benefits such as facilitating the determination of a net present toll value and facilitating the automatic modification of trip routes based on meeting a net present toll value threshold. In order to calculate the net present toll value, systems determine the total cost of the trip route based on aggregating a set of toll fees included in the subset of the plurality of toll transaction data points included in the correlated trip dataset. Systems also determine the total time of the trip route based on a time difference between a first timestamp of the first telematic data point and a second time stamp of the second telematic data point included in the correlated trip dataset. Systems are then able to generate a net present toll value based on a combination of the total cost of the trip route and the total time of the trip route.

[0188] Some systems are configured to automatically modify a trip route if the corresponding net present toll value does not meet the net present toll value threshold. For example, systems identify a net present toll value threshold associated with the trip or set- Page 42 - Docket No. 3400.408AWOof trips and determine whether the net present toll value meets or exceeds the net present toll value threshold based on comparing the net present toll value against the net present toll value threshold.

[0189] In response to determining that the net present toll value meets or exceeds the net present toll value threshold, systems refrain from modifying a future trip route based on the trip route as traveled according to the correlated trip dataset. Alternatively, in response to determining that the net present toll value does not meet the net present toll value threshold, systems modify the future trip route.

[0190] The net present toll value and determination of whether the net present toll value threshold is met can be displayed to a user at a user interface. The user interface is also updated with potential trip modifications, including prompts to the user to confirm or deny the modifications. For example, in response to generating the net present toll value, systems dynamically update the second window to display the net present toll value at a third location of the second window.

[0191] In response to determining that the net present toll value meets or exceeds the net present toll value threshold, systems dynamically update the net present toll value according to a first formatting indicating that the net present toll value meets or exceeds the net present toll value threshold.

[0192] In response to determining that the net present toll value does not meet the net present toll value threshold, systems dynamically update the net present toll value according to a second formatting indicating that the net present toll value does not meet the net present toll value. Additionally, in response to modifying the future trip route, systems dynamically update the second window to display a modification to the trip route displayed using the geographical map. By implementing systems in this manner, users are able to visualize the trip modifications and corresponding increase in net present toll value in order to make more informed decisions and realize greater time and money savings.

[0193] There are different ways in which the system can modify a trip in order to facilitate a trip modification that will result in an increased net present toll value. For example, if a trip is incurring an excess in toll fees, without realizing sufficient time savings, the system may modify the route to avoid a certain toll road or set of toll roads in favor of a non-tolled route that has similar time estimates. Alternatively, if a non-tolled route is incurring too much time latency but a tolled route would provide decreased travel times, the system can modify the trip route to include the tolled portion of the route.- Page 43 - Docket No. 3400.408AWO

[0194] In other words, modifying the trip routes includes an additional toll transaction fee based on traveling through an additional tolled checkpoint between the first coordinate location and the second coordinate location such that the future trip corresponds to a new net present toll value that meets or exceeds the net present toll value threshold. Additionally, or alternatively, systems exclude a toll transaction fee in the correlated trip dataset based on refraining from traveling through a tolled checkpoint associated with the toll transaction fee such that the future trip corresponds to a new net present toll value that meets or exceeds the net present toll value threshold.

[0195] There are many technical benefits achieved by providing a correlated dataset of telematic and toll transaction data. For example, systems are achieving improved accuracy in predicting a toll bill for a particular trip of a vehicle. This improved predicted toll bill can then be used to compare with the actual toll bill to identify any errors in the toll bill. For example, systems access a toll information database comprising toll fee schedules and toll locations for different toll agencies. Based on the subset of the plurality of telematic data points for the trip route, systems identify one or more telematic data points that correspond to one or more toll fee schedules and toll locations included in the toll information database. Then, based on identifying the one or more telematic data points that correspond to the one or more toll fee schedules and toll locations included in the toll information database, systems predict one or more toll transactions for the trip route.

[0196] Systems also compare the predicted one or more toll transactions for the trip route with the subset of the plurality of toll transaction data points and identify a difference between at least one of the one or more toll transactions that were predicted for the trip route and at least one of the subsets of the plurality of toll transaction data points. Finally, systems generate an alert message indicating that the at least one of the subsets of the plurality of toll transaction data points includes an error.

[0197] Systems can also identify additional errors in the correlated dataset, including identifying toll transaction data points without corresponding telematic data points (i.e., extra toll bills that are improperly recorded or to detect abuse and fraud in the user of a vehicle transponder).

[0198] For example, systems predict a continuous route corresponding to the trip route based on the subset of the plurality of telematic data points and generate a new set of telematic data points comprising the subset of the plurality of telematic data points and a set of predicted coordinate data points located between different telematic data points of the subset of the plurality of telematic data points. Systems also identify one or more toll- Page 44 - Docket No. 3400.408AWOtransaction data points from the subset of the plurality of toll transaction data points that were not included in the correlated trip dataset and that are predicted to correspond to the set of predicted coordinate data points and generate an alert message indicating that one or more toll transaction data points do not have a corresponding telematic data point included in the new set of telematic data points.

[0199] In some instances, systems are also configured to identify telematic data points that do not have corresponding toll transaction data points (i.e., unread transponder errors, and pre-violation identification). For example, systems access a toll checkpoint database comprising a plurality of toll checkpoint data points. Each toll check data point comprises a toll checkpoint location and a toll fee schedule. Systems query the subset of the plurality of telematic data points against the toll checkpoint database.

[0200] Based on querying the subset of the plurality of telematic data points against the toll checkpoint database, systems identify a telematic data point of the subset of the plurality of telematic data points that corresponds to a toll checkpoint data point included in the toll checkpoint database and determine that the telematic data point of the subset of the plurality of telematic data point does not correspond to a toll transaction data point of the subset of the plurality of toll transaction data points.

[0201] In response to determining that there is not a corresponding toll transaction data point, systems generate an alert message indicating that the telematic data point that should have had a corresponding toll transaction data point missing the corresponding toll transaction data point.

[0202] Some systems are also configured to detect abuse and fraud by comparing telematic trip data against a predicted set of telematic data. If there are discrepancies between the actual trip and the planned route, systems are configured to alert fleet managers. For example, systems identify a predetermined planned route associated with the trip route, the trip route being an actual trip route recorded using the telematic tracker and compare the subset of the plurality of the telematic data points with the predetermined planned route.

[0203] Based on comparing the subset of the plurality of the telematic data points with the predetermined planned route, systems identify a difference between the predetermined planned route and the subset of the plurality of the telematic data points. If a difference is identified, systems generate an alert message that the difference between the predetermined planned route and the subset of the plurality of the telematic data points has been identified.- Page 45 - Docket No. 3400.408AWO

[0204] In some instances, systems are also configured to monitor and modify tag distributions, in order to provide optimized tag distributions by relocating tag assignments to different home agencies in order to realize the greatest monetary savings across multiple fleets of vehicles. For example, systems access a tag fee database comprising tag fee information from a plurality of toll agencies and access a set of assigned vehicle tags associated with one or more customer fleets. Systems then compare the correlated dataset against the tag fee information included in the tag fee database. Based on comparing the correlated dataset against the tag fee information, systems determine whether one or more vehicle tags should be reassigned to a different location of a particular toll agency. In response to determining that one or more vehicle tags should be reassigned to the different locations of the particular toll agency, systems modify the set of assigned vehicles by reassigning one or more vehicle tags to the different locations of the particular toll agency.RENTAL FLEET MANAGEMENT

[0205] As referenced above, the disclosed embodiments are directed to methods for improved real-time and near-real-time rental fleet management. Notably, while the disclosed embodiments below are discussed as pertaining to rental fleets, it should be appreciated that the systems, methods, and benefits achieved, are also applicable to any type of vehicle fleet or vehicles, including service companies such as plumbers, delivery drivers, rideshare providers, etc., or other companies that will benefit from being able to provide real-time estimations and calculations of tolls to their customers for faster, more efficient invoicing. For example, when a service provider completes a job or a delivery, at the time of invoicing, the service provider and / or customer is able to access the calculated tools from the toll-telematics system. In this manner, the service provider is able to include any calculated toll fees and the service fees on the invoice.

[0206] Attention will now be directed to Fig. 15, which illustrates an example overview of a rental vehicle along a trip route during a rental period. Fig. 15 shows a rental vehicle company 1502 located at a particular location within a geographic area. Rental vehicle company 1502 rents out various rental vehicles from their vehicle fleet to different customers for customizable rental periods. Rental vehicle 1504 is rented by a particular customer and driven away from the rental vehicle company 1502. The rental vehicle 1504 is driven along a route by the customer and may incur toll fees along the way.

[0207] In conventional systems, when the rental vehicle is returned to the rental vehicle company 1502, a final rental invoice is generated at the point of return, either electronically or physically, at which point the customer pays for any rental fees associated- Page 46 - Docket No. 3400.408AWOwith renting the vehicle for the rental period. In conventional systems, the rental vehicle company 1502 has no way to calculate or even estimate the toll fees that were incurred during the rental period. Weeks later, the rental vehicle company 1502 will have to send a separate toll bill to the customer (after the toll companies send the toll bill to the rental vehicle company 1502). At this point, the customer will likely have thought that everything was already paid for and find the toll bill startling. It also causes the user experience with renting the vehicle to be disjointed and complicated in this multi-step billing process. Additionally, in conventional systems and processes, it is very difficult for the customer or the rental company to identify any errors in the toll bill. If the customer does not pay the toll bill, the rental car company may be responsible for covering the toll bill associated with their rental vehicle.

[0208] Thus, the disclosed embodiments are directed to improved systems and methods for real-time and near-real-time rental fleet tracking and management, including providing an estimated total toll bill at the point of return for the rental vehicle.

[0209] According to the disclosed embodiments herein and as shown in Fig. 15, once the rental vehicle 1504 leaves the particular location of the rental vehicle company 1502, or at the start of a rental period, a telematic tracker disposed on the rental vehicle 1504 begins to track telematic data for the rental vehicle. The telematics data comprises GPS coordinates and timestamps along a predetermined and / or dynamically changing route (e.g., route 1506).

[0210] These telematic data points (e.g., telematic data point 1510A, telematic data point 1510B, telematic data point 1510C, telematic data point 1510D, telematic data point 1510E, telematic data point 1510F, telematic data point 1510G, telematic data point 1510H, and telematic data point 1510 J) are tracked, stored (either locally or at a remote hardware storage device after transmission), and transmitted to a telematics server. In some instances, these telematic data point are transmitted continuously in real-time throughout the rental period, transmitted periodically, and / or transmitted in response to a request to transmit one or more telematic data points.

[0211] In some instances, the customer may drive the rental vehicle on routes that will incur toll fees at various toll checkpoints or gantries (e.g., toll 1508A, toll 1508B, toll 1508C, toll 1508D). These toll fees are incurred via any of the various methods described herein (e.g., using a toll transponder, vehicle license plate, etc.). Systems are able to correlate telematic data points with toll checkpoints (e.g., telematic data point 1510B corresponds with toll 1508 A, and telematic data point 1510D corresponds to toll 1508B).- Page 47 - Docket No. 3400.408AWOThese telematic data points are referred to as toll -triggering telematic data points. When the system identifies a toll-triggering telematic data point, the system is able to access a local or remote toll information database which stores or queries for toll fee schedules for the particular toll checkpoint. The system is also able to identify any other characteristics of the vehicle (e.g., vehicle weight) or other information associated with the telematic data point (e.g., timestamp) to determine which toll fee will be applied to the rental vehicle by the respective toll company owning the particular toll road at that toll checkpoint. The toll fee is calculated based on the characteristics of the vehicle, timestamp, GPS location, and toll fee schedule. All calculated toll fees are aggregated to provide an estimated total toll fee, also referred to as a calculated total toll fee.

[0212] In some instances, the system is able to infer that a toll will be applied to the rental vehicle based on correlating two consecutive telematic data points and determining that no other route or that the most likely route of the vehicle would have incurred a toll. For example, telematic data point 1510F and telematic data point 1510G are consecutive telematic data points along a particular toll route. Toll 1508C may be a toll bridge gantry, such that the bridge at that point of the route is the only way or most likely way to cross over to the geographic area associated with telematic data point 1510G. Thus, even though a particular telematic data point did not correspond directly to the toll 1508C, the system is able to predict that the rental vehicle incurred a toll fee at that toll checkpoint based on correlating the two consecutive telematic data points.

[0213] Similarly, in some instances, the system will predict that the rental vehicle incurred a toll fee at toll 1508D based on correlating telematic data point 1510G and telematic data point 1510H. However, as shown in Fig. 15, there is a geographic area and / or period of time in which no telematic data points were tracked between telematic data point 1510G and telematic data point 1510H. This is referred to as an omission region or omission time period where no telematic data was tracked. It is possible that there were many different routes that the rental vehicle could have traveled between telematic data point 1510G and telematic data point 1510H, some of which may have incurred a toll fee at toll 1508D, some of which may have incurred a different toll fee at a different toll location, and / or some of which may not have incurred any toll fees at all.

[0214] These areas of omission can be identified and included in the rental invoice, as alerts to both the rental vehicle company and / or rental vehicle customer that there may be errors in the predicted toll transaction data and resulting estimated total toll fee. However, by tracking regions and time periods of omission, the system is able to predict the most- Page 48 - Docket No. 3400.408AWOlikely routes and still provide predicted toll transaction data without having to correlate specific telematic data points with toll checkpoints.

[0215] In some instances, a user has a mobile application running on a personal mobile device that tracks the telematics data, identifies toll checkpoints, and estimates toll fees. The estimated toll fees could be based on actual telematics data or based on routes designated in a routing mobile application. Additionally, or alternatively, in some embodiments, the mobile application comprises a user interface for the user to manually input toll locations that were passed through and / or stopped at and paid for. In some instances, the application is configured to prompt the user to manually input or mark toll locations or save routes taken using a navigation application if the system detects that it is experiencing an omission geographic region or time period and cannot track, store, and / or transmit any telematics data.

[0216] Attention will now be directed to Fig. 16, which illustrates an example triggering event for generating a rental invoice with an estimated total toll fee along with the rental fee. As described previously, in conventional systems, a rental invoice is generated (without any actual or estimated toll fees) once the rental vehicle is checked back into the rental vehicle company. However, in order to provide improved customer experiences for renting vehicles and improved rental fleet management by rental vehicle companies, the disclosed embodiments are directed to detecting a triggering event (e.g., alert 1606) that occurs prior to the point of return of the vehicle that triggers the generation of a request to generate the final rental invoice, including a request to generate an estimated total toll fee to present within the final rental invoice. This estimated total toll fee is a calculated total fee based on calculating the toll fee incurred by each toll-triggering event identified or predicted by the system. Because the total toll fee is calculated based on actual telematics data and up-to-date toll fee schedules provided by the toll agencies, these calculated toll fees are accurate enough to be the basis to collect payment from the customer for these toll transactions, without having to wait for the toll bill sent out by the toll agency.

[0217] For example, as shown in Fig. 16, systems are able to detect when a rental vehicle 1604 enters a geographic zone 1608 associated with the vehicle return 1602 at the rental vehicle company (e.g., rental vehicle company 1502). In some instances, the triggering event is further conditioned on the rental vehicle entering the geographic zone during the rental period, prior or subsequent to a predetermined rental period termination, or during a rental return window 1610 within or comprising at least a portion of the rental- Page 49 - Docket No. 3400.408AWOperiod. In some instances, the triggering event is further conditioned upon detecting that the rental vehicle has remained within the geographic zone for a particular amount of time or remained in the geographic zone for a particular amount of time within the rental return window.

[0218] In some instances, the rental return window 1610 is predetermined by the rental vehicle company according to company policies. The geographic zone is also predetermined and comprises the vehicle return 1602. In some instances, the geographic region comprises a circular area having a specific radius that corresponds to a particular distance from the vehicle return. In some instances, the geographic zone corresponds to specific routes that lead back to the vehicle return 1602 from various directions. It should also be appreciated, that in some instances, the triggering event is only conditioned upon detecting an end or near-end of the rental period without geographic location conditions.

[0219] By detecting a triggering event (e.g., alert 1606) prior to the rental vehicle 1604 arriving at the vehicle return 1602, the system is able to generate a request to estimate the toll fees and allows the system ample time to receive the estimated toll fees and generate the final rental invoice, including both rental fees and estimated toll fees, so that the rental invoice is ready for the customer when the customer arrives at the vehicle return 1602. In some instances, only the estimated toll fees are included in the prepared rental invoice, as some rental fees may be associated with the final inspection of the rental vehicle at the point of return. However, in either case, the customer is provided with a rental invoice that beneficially includes both the rental fees and the estimated toll fees, without having to wait at the rental vehicle company and without having to wait for a toll bill to be sent weeks later after the rental vehicle has already been returned and paid for.

[0220] In this manner, the customer experience is greatly improved, both in efficiency of the rental vehicle return and in transparency of fees associated with their rental vehicle during the rental period. As additional benefits, the rental vehicle company is able to provide this streamlined customer experience, reduce the time and cost associated with rental fleet management and return, as well as collect payment upfront for the estimated toll fees. In this manner, the rental vehicle company is able to avoid losses associated with paying the toll fees that may have been left unpaid if the customer had received the bill later.

[0221] Also, by providing an estimated total toll fee at the point of return, the customer is able to inspect the estimated toll fee and identify any potential errors, as their trip route is fresh in their memory. They also may be able to indicate any times they noticed that the- Page 50 - Docket No. 3400.408AWOtransponder wasn’t working, if they had to pay any of the tolls directly during the rental period, or other issues (e.g., they didn’t take a certain route associated with an estimated toll fee).

[0222] The rental vehicle company will then be able to flag those estimated toll fees and compare the estimated toll fees against any actual toll transactions included in the toll bill sent by the different toll agencies and ensure that the toll bill does not have any errors. If there are errors, the rental company will have both the telematics data, as well as customer-provided notes and / or evidence, for why one or more toll transactions are wrong in the toll bill.

[0223] Attention will now be directed to Figs. 20-22, with reference to Figs. 15-19, which illustrate various flowcharts associated with methods for tracking and managing rental fleets. Notably, Fig. 17 illustrates an example process flow diagram for communication between a vehicle, a telematics server, and a rental server. Fig. 18 illustrates various example rental invoice displays, including the presentation of the estimated total toll fee and / or the rental fee, and Fig. 19 illustrates an example car interior, with various example embodiments for displaying an estimated running or total toll fee.

[0224] Attention will now be directed to Fig. 20, which illustrates a process flow diagram comprising a plurality of acts (act 2010, act 2020, act 2030, act 2040, act 2050, act 2060, and act 2070) associated with a method for generating a rental invoice including estimated toll fees at point of return from the perspective of a telematics server.

[0225] For example, a first illustrated act is provided for receiving, at a first computing server (e.g., telematics server 1708), a plurality of telematic data points (e.g., telematics data 1706) from a telematic tracker (e.g., telematic tracker 1704) associated with a rental vehicle (e.g., vehicle 1702) during a rental time period (act 2010). In response to receiving the telematic data points, systems access a toll information database (e.g., toll information database 1712) including toll fee schedules (e.g., toll fees 1716) and toll locations (e.g., toll locations 1714) for different toll agencies (act 2020). Based on the plurality of telematic data points, systems identify one or more toll -triggering telematic data points (e.g., toll-triggering telematics data 1718) from the plurality of telematic data points during the rental time period that correspond to one or more toll fee schedules and toll locations included in the toll information database (act 2030).

[0226] Based on identifying the one or more toll -triggering telematic data points, systems (e.g., telematics server 1708) predict one or more toll transactions (e.g., predicted toll transactions 1720) incurred by the rental vehicle during the rental time period that is- Page 51 - Docket No. 3400.408AWOassociated with the one or more toll triggering telematic data points (act 2040). Systems are configured to receive a request (e.g., request 1724), from a second computing server (e.g., rental server 1722), for generating an estimated total toll fee associated with the rental vehicle during the rental time period (act 2050). In response to receiving the request, systems generate the estimated total toll fee (e.g., estimated total toll fee 1726) by identifying and aggregating the one or more predicted toll transactions for the rental vehicle during the rental time period (act 2060). Finally, after generating the estimated total toll fee, systems transmit, to the second computing server, the estimated total toll fee, which can then be presented within a rental invoice (e.g., rental invoice 1730) along with any rental fees (e.g., rental fees 1728) typically included in the rental invoice (act 2070).

[0227] It should be appreciated that there are multiple different triggering events or processes that trigger the generation of the request to estimate the toll transaction data. For example, in some instances, the request is automatically generated in response to detecting the telematic tracker corresponding to the rental vehicle entering a predetermined geographic zone associated with a rental vehicle company. In some instances, the request is automatically generated in response to detecting the telematic tracker corresponding to the rental vehicle entering a predetermined geographic zone associated with a rental vehicle company within a predetermined return time window. In some instances, the request is automatically generated in response to detecting the telematic tracker corresponding to the rental vehicle entering and remaining for a certain amount of time, in a predetermined geographic zone associated with a rental vehicle company within a predetermined return time window.

[0228] Additionally, or alternatively, in some instances, the request is automatically generated in response to detecting the telematic tracker passing through a vehicle return checkpoint including a sensor configured to detect the telematic tracker, while in other instances, the request is automatically generated in response to detecting the telematic tracker passing through a vehicle return checkpoint including a vehicle license imaging device configured to automatically capture an image of a license plate on the rental vehicle.

[0229] The request can also be automatically generated in response to receiving user input via a user interface including at least a selectable icon that when selected triggers the request being generated. For example, typically a vehicle return attendant will greet a customer at the point of return and perform a final inspection of the vehicle. Some attendants utilize mobile devices that have user interfaces for facilitating the vehicle return, such as capturing photographs of the rental vehicle and for including notes and / or- Page 52 - Docket No. 3400.408AWOdescription of the vehicle. These user interfaces can beneficially include selectable icons that when selected by a user trigger the generation of a request for generating the final rental invoice. This request also triggers a request for generating an estimated total toll fee, which is transmitted to a remote telematics server that is configured to perform toll transaction estimation.

[0230] In any of these aforementioned invoice-triggering events, even with limited lead time, the system is able to generate a calculated total toll fee quickly and provide it as part of the final invoice because the system is identifying toll transactions and calculating toll fees through the whole rental period. Thus, most of the data is pre-calculated and ready to be sent on request. In some instances, only a limited set of toll fees need to be calculated for the final portion of the trip and aggr egated / added to the total amount when a request is received to calculate the total toll fee, allowing for the fast turn-around time for completing the request.

[0231] In some instances, systems (e.g., telematics server 1708) further receive a request for generating a trip summary (e.g., a request for evidence associated with the calculated toll fees) associated with the rental vehicle within the rental time period, the trip summary including a correlated dataset including the plurality of telematic data points correlated with the one or more predicted toll transactions; and transmitting the trip summary to be presented with the rental invoice. This trip summary and / or correlated dataset may be provided as validation information to validate any estimated toll fees. As shown in Fig. 18, additional validation information may also be requested from the telematics server and transmitted to be included in rental invoice 1802 (representative of rental invoice 1730).

[0232] Validation information 1808 comprises one or more of the following: toll transaction data 1810, a correlated map 1812, omission regions 1814, and / or omission time periods 1816. If there are omission regions or time periods, the rental invoice may comprise a warning to the customer that they will be responsible for additional toll fees that are identified in the toll bill sent by the toll agency to the rental car company or directly to the customer, as the system may not be able to accurately predict toll transaction data during those periods or regions of omission.

[0233] Thus, subsequent to transmitting the estimated total toll fee, systems are configured to receive a new request for validation information used in generating the estimated total toll fee. The validation information includes one or more of the plurality of telematic data points from the telematic tracker associated with the rental vehicle during a- Page 53 - Docket No. 3400.408AWOrental time period and / or a correlated geographic map. Additionally, the validation information further includes the omission geographic regions and / or time periods that did not have data transmission, if requested. It will be appreciated that the validation information may be transmitted in response to receiving a separate request for the validation information or provided automatically as part of the original request to calculate the estimated total toll fee to be included in the rental invoice.

[0234] In addition to generating an estimated total toll fee, systems are also able to maintain and update an estimated running or cumulative toll fee during the rental period. In such instances, prior to receiving the request to generate the estimated total toll fee, systems are configured for receiving a new telematic data point from the telematic tracker. In response to receiving a new telematic data point, systems identify one or more toll fee schedules and toll locations included in the toll information database that correspond to the new telematic data point and generate a predicted toll transaction for the new telematic data point.

[0235] In this manner, systems are beneficially able to generate, in real-time or near- real-time, an estimated running toll fee including at least the predicted toll transaction. This estimated running toll fee may be queried and / or transmitted at any point during the rental period of the rental vehicle. For example, systems can transmit the estimated running toll fee to a user interface configured to display the estimated running toll fee. The user interface may be a physical document (e.g., document 1818), displayed within a mounted or integrated display screen within the vehicle (e.g., display 1822) (see, also, Fig. 19), or within a mobile application on a mobile device (e.g., mobile device 1820), such as a cell phone or tablet.

[0236] Attention will now be directed to Fig. 21, which illustrates a process flow diagram comprising a plurality of acts associated with a method for generating a rental invoice including estimated toll fees at the point of return from the perspective of a rental server.

[0237] For example, systems detect a telematic tracker (e.g., telematic tracker 1704) corresponding to a rental vehicle (e.g., vehicle 1702) entering a predetermined geographic zone associated with a rental vehicle company within a predetermined return time window. In response to detecting the telematic tracker entering the predetermined geographic zone within the predetermined return time window, systems automatically generate a request (e.g., request 1724), at a rental car server (e.g., rental server 1722), to generate an estimated- Page 54 - Docket No. 3400.408AWOtotal toll fee based on a correlated trip dataset corresponding to a rental time period associated with the rental vehicle.

[0238] In response to generating the request, systems automatically transmit the request from the rental car server to a remote telematics server (e.g., telematics server 1708). Systems then receive, from the remote telematics server, the estimated total toll fee (e.g., estimated total toll fee 1726) that is generated by identifying and aggregating one or more predicted toll transactions (e.g., predicted toll transaction 1720) for the rental vehicle during the rental time period. Finally, systems generate a rental invoice (e.g., rental invoice 1730) that presents rental fees (e.g., rental fees 1728) and the estimated toll fees (e.g., estimated total toll fee 1726) within the rental invoice at the point of return of the rental vehicle.

[0239] In some instances, after generating the rental invoice, systems automatically display the rental invoice with the estimated total toll fee and a rental fee within a customer-facing user interface. Additionally, the customer -facing user interface includes one or more selectable icons for increasing or decreasing the granularity of detail corresponding to the rental invoice.

[0240] As shown in Fig. 18, the rental invoice 1802 (representative of rental invoice 1730), in some instances, further comprises validation information 1808, including toll transaction data 1810, a correlated map 1812, omission regions 1814, and / or omission time periods 1816. The rental invoice can then be displayed as a document 1818, at a display 1822, or on a mobile device 1820. The amount of validation information can be tuned automatically based on detected characteristics of the rental invoice and / or based on user input associated with increasing or decreasing the granularity of detail corresponding to the rental invoice, as described above.

[0241] It should be appreciated that there are several different methods by which to detect the triggering event for generating the request for the estimated total toll fee and / or rental invoice. For example, in some instances, the telematics tracker will track and detect when the vehicle enters the geographic zone within the predetermined rental return window and sends an alert / request to either the rental car server (which then in turn automatically generates and transmits a request to the telematics server to generate the estimated total toll fee) or directly to the telematics server to generate the estimated total toll fee (which then transmits the estimated total toll fee to the rental car server.

[0242] Additionally, or alternatively, either the telematics server and / or rental car server is configured for detecting the triggering event. In instances where the rental car- Page 55 - Docket No. 3400.408AWOserver is configured for detecting the triggering event, the rental car server includes a sensor for detecting a proximity of the rental car within the predetermined geographic zone, using either the telematics tracker in communication with the telematics server and rental car server, or a separate GPS tracker that is owned by the rental car company and is in communication with the rental car server.

[0243] In instances where the telematics server is configured to detect the triggering event, the rental car server will receive a notification from the remote toll -telematics server that the telematic tracker corresponding to the rental vehicle entered the predetermined geographic zone associated with the rental vehicle company within the predetermined return time window.

[0244] Attention will now be directed to Fig. 22, which illustrates a process flow diagram comprising a plurality of acts associated with a method for generating and displaying estimated toll fees, such as cumulative toll fees, associated with tolls incurred by a vehicle during a service rental period associated with the vehicle.

[0245] For example, a first illustrated act is provided for tracking telematics data (e.g., telematics data 1706) associated with the vehicle during the service rental period (act 2210) and transmitting the tracked telematics data to a telematics server (e.g., telematics server 1708) (act 2220). Systems then receive toll transaction data (e.g., predicted toll transactions 1720) from a telematics server during the service rental period based at least in part on the transmitted telematics data (act 2230). After receiving the predicted toll transaction data, systems cause to be displayed the received toll transaction data at a display (e.g., display 1710) contained within the vehicle during the service rental period (act 2240).

[0246] For example, as shown in Fig. 19, there are several different configurations of the vehicle interior 1902 to provide real-time and / or periodic display of predicted toll transaction data, either as a running list of predicted toll transactions, a cumulative running toll fee during the rental period, or an estimated total toll fee nearing or at the end of a rental period. As shown in Fig. 19, display 1710 can be configured as part of the rear-view mirror 1908, which comprises a small, embedded screen or digital display within the rearview mirror. Alternatively, display 1710 is configured as part of a console display (e.g., console display 1906), which comprises a user interface that can be selected to display the various types of predicted toll transaction data. As shown in Fig. 19, the display may also be configured as a secured or detachably mounted display 1904 located in an area visible to the driver or other passengers, such as on the dash of the vehicle interior 1902.- Page 56 - Docket No. 3400.408AWO

[0247] In some instances, the display includes a hardware display mounted to an interior portion of the vehicle. In some instances, the display includes a mobile device that is detached from the vehicle. In such instances where the mobile device is detached from the vehicle, the display includes a user’s mobile phone.

[0248] It should be appreciated that the systems are configured to update the tracked telematics data based on any movement of the vehicle during the service rental period. The tracked / updated telematics data can then be transmitted to the telematics server during the service rental period. The telematic server is then able to predict toll transaction data based on the updated telematics data, wherein systems (e.g., a vehicle server) receive the updated toll transaction data based on the updated telematics data and display the updated toll transaction data at the display based on the updated toll transaction data.

[0249] Such systems, methods, and interfaces can be used as part of any service vehicle or service fleet. For example, a rideshare or taxi-cab vehicle may be equipped with a display (e.g., display 1710) configured as any of the embodiments shown in Fig. 19, wherein a rider is able to view and / or access the running total of the fees incurred. For example, the display may be configured to display the running ride fee for the time / distance of the ride, as well as the calculated running total of any toll fees that have been incurred during the ride. Thus, in some embodiments, display 1710 is configured to display the running ride fee separately from the running calculated total toll fee (and / or list of individual toll fees). Alternatively, the display 1710 is configured to display a single running total amount that includes both the ride fees and the toll fees.

[0250] In some instances, the system is also configured to generate an alert when a new toll fee has been calculated and added to the display (either to a running list of toll fees, a total toll fee, or the combined total toll and ride fee). The alert can be configured in a variety of different ways, such as a sound alert, a light alert, a display notification on the user interface / display, and / or a notification on a user’s device (e.g., through a mobile application or a text message or email, etc.), or any combination thereof.

[0251] It will be appreciated that the disclosed embodiments provide many technical benefits over conventional systems and methods for rental fleet management. For example, the disclosed embodiments provide real-time and near-real-time rental fleet management, including real-time and near-real-time estimated toll transaction data that can be used to streamline the rental process for both rental vehicle companies and rental vehicle customers.- Page 57 - Docket No. 3400.408AWO

[0252] It should be appreciated that any of the disclosed embodiments related to telematics tracking, correlated trip datasets, calculating net present toll values, identifying toll bill errors, identifying pre-violations, identifying vehicle fraud and abuse, assigning tags, and other pre-trip, en route, and post-trip analytics, are also applicable to rental fleet management.

[0253] For example, telematics tracking, toll agency databases, and correlated trip datasets are used to predict toll transactions for rental vehicles. Additionally, net present toll values can be generated for rental vehicle companies and customers. The disclosed embodiments related to rental fleet management also achieve technical benefits associated with toll bill error detection and mitigation, as well as being able to identify and alert customers and rental car companies about pre-violations or re-occurring violations. Disclosed systems are also beneficial in identifying and preventing rental vehicle fraud and abuse. Rental vehicle companies will also benefit from the systems and methods described herein for assigning and distributing vehicle tags.VEHICLE FLEET ROUTING MANAGEMENT

[0254] Attention will now be directed to Figs. 23A-34, which illustrate different aspects of a fleet routing management software, including providing net toll value analytics for different trip routes and toll fees. As described above, particularly with respect to Fig. 10, systems are provided for determining a net toll value for a trip or portion of a trip. The net toll value is compared against a net toll value threshold. If the net toll value meets or exceeds the net toll value threshold, the system generates a recommendation to continue using the same route. If the net toll value does not at least meet the net toll value threshold, the system generates a recommendation to discontinue the route associated with that deficient net toll value. The following embodiments are directed to systems and methods for determining alternate routes in instances where the net toll value does not meet the net toll value threshold, or to further improve the net toll value, even if it does meet or exceed the net toll value threshold. In some instances, the system is configured to select routes based on route valuations falling below a certain threshold (e.g., a maximum time or cost). The routing management systems are also further customizable based on different criteria such as optimization metrics, constraints, or other routing decision factors.

[0255] Attention will now be directed to Fig. 23 A, which illustrates an example of a set of trips routes that include an overlapping portion along a tolled road. Fig. 23 A shows a set of trips (e.g., Trip 1, Trip 2, and Trip 3). The set of trips are associated with- Page 58 - Docket No. 3400.408AWOapproximately the same day and time of day, such that tolls incurred along the route are approximately equal at each gantry based on the tolling agency’s toll schedules. It should be appreciated that while Fig. 23 A illustrates three different trips, any number of trips can be included in the set of trips. As shown in the figure, each of the trips have different starting locations (e.g., Start 1, Start 2, and Start 3) and ending locations (e.g., End 1, End 2, and End 3). However, even though the trips have different starting and ending locations, there is an overlapping trip portion 2302 where each of the trips follow the same route or portion of the traversable road infrastructure.

[0256] Here, the overlapping trip portion comprises a route along a tolled portion of the road. It should be appreciated that while Fig. 23 A illustrates an overlapping trip portion that corresponds to tolled road only, the overlapping trip portion for the set of trips may comprise non-tolled road, or a combination of tolled and non-tolled road. As shown, the overlapping trip portion 2302 comprises the following toll gantries: G3, G4, G5, G6, and G7. As described previously, a toll gantry is a location along a tolled road where a toll charge is incurred, either as an entry, an exit, a pass-through gantry, or combination thereof.

[0257] It should also be noted that Fig. 23 A illustrates, as an example, an overlapping trip portion 2302 that corresponds to each of the different trips (e.g., Trip 1, Trip 2, and Trip 3). In some instances, the system identifies a subset of the trips that correspond to a different (longer or shorter overlapping trip portion). For example, in other instances, the system considers Trip 2 and Trip which has an overlapping trip portion comprising gantries: G2, G3, G4, G5, G6, and G7, which is a longer overlapping trip portion than overlapping trip portion 2302. In either instance, once the system identifies an overlapping trip portion between two or more different trips, the system determines if there are any alternate routes available that could replace the overlapping trip portion to yield an improved overall route. If there are alternate routes available, the system identifies each of the different alternate routes. If there are no alternate routes available, the system indicates that the current route is the recommended route and no modifications are made.

[0258] Attention will now be directed to Fig. 23B, which illustrates various alternate routes that are available in lieu of the current overlapping trip portion corresponding to Trip 1, Trip 2, and Trip 3. As shown in Fig. 23B, there are a plurality of different alternate routes that could be used instead of the overlapping trip portion or instead of a certain part of the overlapping trip portion. Fig. 23B is shown illustrating the following alternate routes: alternate route 2304, alternate route 2306, alternate route 2308, and alternate route- Page 59 - Docket No. 3400.408AWO2310. Alternate route 2304 begins at gantry G2 and ends just after gantry G7 before the different trips split off to their different ending locations. Alternate route 2306 begins between gantry G2 and gantry G3 and ends between gantry G4 and gantry G5. Alternate route 2308 beings at gantry G4 and ends at gantry G7. Alternate route 2310 begins between gantry G2 and gantry G3 and ends at gantry G5. It should be appreciated that while each of the illustrated alternate routes comprise non-tolled infrastructure, the system is able to identify alternate routes that comprise alternate tolled infrastructure and / or a combination of tolled and non-tolled road.

[0259] In some instances, after identifying the different alternate routes, the system then evaluates each of the different alternate routes to determine if one or more of the alternate routes would yield a higher net toll value than the current overlapping trip portion 2302. As shown in Fig. 23C, the system is able to determine that by replacing part of the overlapping trip portion with alternate route 2308 yields a higher net toll value for each of the different trips. The system will then provide new routing instructions for each of the different trips in the set of trips to now include alternate route 2308 instead of the previously used tolled road between gantry G4 and gantry G7.

[0260] Attention will now be directed to Fig. 24, which illustrates an example of process flow diagram for generating a mixed trip route based on different tolled and nontolled route segments that could be used as an alternate route to the current overlapping trip portion. For example, Fig. 24 illustrates a full toll route 2402, which is representative of the overlapping trip portion 2302 of Fig. 23 A. Gantry 2404 is representative of gantry G3, gantry 2406 is representative of gantry G4, gantry 2408 is representative of gantry G5, gantry 2410 is representative of gantry G6, and gantry 2412 is representative of gantry G7.

[0261] After identifying the overlapping trip portion, which in this example is full toll route 2402, the system divides the overlapping trip portion into a plurality of trip segments. As shown in Fig. 24, segmented toll route 2414 comprises Segment Tl, Segment T2, Segment T3, and Segment T4. Segment Tl represents the tolled road associated with gantry G3 to gantry G4. Segment T2 represents the tolled road associated with gantry G4 to gantry G5. Segment T3 represents the tolled road associated with gantry G5 to gantry G6. Segment T4 represents the tolled road associated with gantry G6 to gantry G7.

[0262] It should be appreciated that while Fig. 24 illustrates the full toll route 2402 being divided into route segments that are associated with tolled road from a first gantry to a second gantry, the system is able to segment the full toll route 2402 into any number- Page 60 - Docket No. 3400.408AWOof segments, including generating segments that are associated with no gantries, a single gantry, or more than two gantries.

[0263] After dividing the full toll route 2402 into the segmented toll route 2414, the system then identifies an alternate segment from a full non-toll route 2420 for each segment of the segmented toll route 2414. The full non-toll route 2420 is representative of any alternate route available to replace or augment the overlapping trip portion. As shown in Fig. 24, the system has identified Segment N1 as an alternate route segment for Segment Tl. Similarly, Segment N2 is an alternate route segment for Segment T2. In some instances, the system is able to identify multiple different alternate route segments for a route segments. For example, Segment N3, Segment N3’, and Segment N3” are all available alternate route segments for Segment T3. In some instances, no alternate route segments are available, as illustrated by Segment N4 in dashed lines. Additionally, or alternatively, the system identifies an alternate route segment that corresponds to multiple route segments. For example, Segment N2-3’ is an alternate route segment for the combination of Segment T2 and Segment T2.

[0264] The system then generates a plurality of mixed routes based on different combinations of the tolled segments and non-tolled segments. In other words, the mixed routes comprise different combinations of route segments and alternate route segments. As shown in Fig. 24, one possible mixed route is mixed route 2516. Mixed route 2516 comprises Segment Tl, Segment N2, Segment T3, and Segment T4.

[0265] Attention will now be directed to Fig. 25, which illustrates an example of a plurality of different possible mixed routes. Fig. 25 illustrates mixed route 2502, mixed route 2504, mixed route 2506, and mixed route 2508 which are some of the possible mixed routes that are generated as alternate routes for full toll route 2402. For example, mixed route 2502 comprises Segment Tl, Segment T2, Segment T3, and Segment N4. Mixed route 2504 comprises Segment T2, Segment T2, Segment N3, and Segment T4. Mixed route 2506 comprises Segment Tl, Segment N2, Segment T3, and Segment T4. Segment 2508 comprises Segment Tl, Segment N2, Segment N3, and Segment T4.

[0266] In some instances, the system generates and analyzes a limited set of alternate routes, while in other instances, the system generates and analyzes every possible mixed route based on combinations of segments from the current overlapping trip portion and any available alternate routes.

[0267] Attention will now be directed to Fig. 26, which illustrates an example of comparing, analyzing, and evaluating different route options. In some instances, the- Page 61 - Docket No. 3400.408AWOsystem is configured to determine a total time and a total toll cost for each of the full toll route 2402, full non-toll route 2420, and any mixed routes (e.g., mixed route 2506, mixed route 2508, etc.). The total time and total cost for the full toll route 2402 is 78 min and $17.92, respectively. The total time and total cost for the full non-toll route 2420 is 95 min and $0, respectively. The total time and total cost for mixed route 2506 is 82 min and $15.01, respectively. The total time and total cost for mixed route 2508 is 70 min and $12.92, respectively. Here, whether the system is configured to select an alternate route based on optimizing for time, money, or a combination thereof, mixed route 2508 is the preferred route because it corresponds to the least amount of time (e.g., 8min less than the full toll route 2402) and the least amount of toll cost (e.g., $5 less than the full toll route 2402). Thus, by modifying each of the trips (Trip 1, Trip 2, and Trip 3) with mixed route 2508 (which is representative of alternate route 2308 in Fig. 23C), each of the trips will decrease the trip time by 8 min and decrease the toll cost by $5. This will result in an overall 24 minutes saved and $15 saved across all trips in the set of trips.

[0268] Typical fleet managers are managing routes for hundreds if not thousands of different trips that may have an overlapping trip portion. Thus, the savings are multiplied by the number of trips. Here, if the set of trips comprises 100 trips that each were modified to include the preferred alternate trip route (i.e., mixed route 2508), the fleet manager would be saving 800 minutes of time and $500. This is compounded when multiple segments of a trip are modified across all of the different vehicle fleets. The savings are further compounded when the system identifies repeat trips that are taken multiple times a day, or multiple times a week. If Trips 1, 2, and 3 are taken every weekday of every week for the entire year, the savings are then multiplied by 5 days / week X 52 weeks / year. Thus, it can be seen that even slight modifications or small savings in an individual trip can yield impressive savings over time, compounded by the number of vehicles and trips taken by those vehicles. Furthermore, this method of determining alternate route management is efficient because it is able to analyze large set of trips simultaneously using the identified overlapping trip portion, instead of having to analyze each trip independently. However, as an additional benefit, the systems and methods described herein are also able to analyze individual trips if the need arises.

[0269] Attention will now be directed to Fig. 27, which illustrates an example process for comparing different route options based on a day of the week, day of the year, and time of day. The comparison may also be for particular holidays and / or days in which tolls are free, reduced and / or increased. Traffic patterns may also be compared, such as on a- Page 62 - Docket No. 3400.408AWOweekly, monthly or annual traffic pattern basis, rather than a day and / or hourly basis. While in some instances, the system is able to identify a mixed route that saves both time and money as compared to the current route, in other instances, the system is configured to identify a mixed route that yields an improved net toll value. The net toll value can correspond to a total time, a total toll cost, a toll / time ratio and / or a time value. The toll / time ratio is the ratio of the total toll cost versus the total time. The time value represents the cost of the time that is saved by taking the tolled route as compared to the time and cost of taking a different route.

[0270] In some instances, the data used to determine each of the different metrics include historical data, such that the value identified is an average based on many different historical trips. In some instances, the data is real-time data or predicted data. Additionally, or alternatively, the systems use a combination of the different categories: historical data, real-time data, and / or predicted data, wherein one or more categories of data are weighted more heavily than other categories of data. The categories of data used, and / or weights of the data can be tuned based on the use case scenario for the analytics. For example, if historical trip data is available for a set of trips and the system is working to modify any of the existing trips, the historical data will be used and / or weighted more heavily. If the system predicts that new circumstances will significantly alter the historical data, the predicted data will be weighted more heavily or used instead of the historical data. In another example, if the system is being used to analyze a specific trip that is about to be taken by a driver / vehicle, the real-time data will be weighted more heavily.

[0271] It will also be appreciated that this is not a simple calculation that can be done in the mind of a user, particularly when considering that the time or duration of traversing each segment and the identified routes are based on dynamic time determinations resulting from dynamic conditions in traffic at different instances. Even more particularly, when making the calculations mentioned above, the system may obtain real-time estimates of how long a trip may take. The system can also evaluate historical data to calculate how long a trip would take based on dynamic traffic conditions that were measured at the corresponding estimated time. This may include the system querying third-party systems for traffic records. Weather conditions can also impact travel times. So, the system may also query weather conditions third-party system when determining the estimated time for traversing each segment or segments of the toll routes and the mixed toll routes, based on dynamic weather and traffic conditions, to provide the most accurate time / valuation calculations possible.- Page 63 - Docket No. 3400.408AWO

[0272] Referring back to Fig. 27, the figure illustrates a top chart that evaluates different routes (e.g., a full toll route, a full non-toll route, and a mixed route) on a weekday (e.g., Monday, June 18) at 6:00pm versus a bottom chart that evaluates the same full toll route, full non-toll route, and mixed route but on a weekend day (e.g., Saturday, June 16) at 4:00am.

[0273] On the referenced weekday (e.g., Monday, June 18), the full toll route is associated with a time of 78 min, a toll cost of $17.92, a toll / time ratio of $0.23 / min, and a time value of $1 ,05 / min. The time value is determined by identifying the time of the full toll route versus the time of the full non-toll route. By taking the full toll route, the vehicle saves 17 minutes. However, the tolls equal $17.92. In other words, the vehicle is paying $17.92 to save 17 minutes, yielding a time value of $1.05 per minute saved.

[0274] A similar analysis is done for each of the different routes. The full non-toll route is associated with a time of 95min, a toll cost of $0, a toll / time ratio of $0 / min, and a time value represented by the extra 17 minutes as compared to the faster time associated with the full toll route. The mixed route is associated with a time of 90min, a toll cost of $12.92, a toll / time ratio of $0.14 / min, and a time value of $2.59 / min. Here, while the toll / time ratio appears to indicate that the mixed route yields an improved net toll value, in fact, the time value or cost per minute saved is actually more than the time value determined for the full toll route.

[0275] The system is configurable to maintain, replace, or modify the current overlapping trip portion based on optimizing for time, toll cost, toll / time ratio, and / or time value. If the system is optimized for saving time, the system would maintain the overlapping trip portion as the full toll route. If the system is optimized for saving money, the system would replace the overlapping trip portion with the full non-toll route. If the system is optimized for identifying the least or a lesser toll / time ratio, the system would modify the overlapping trip portion according to the segments included in the mixed route. If the system is optimized for identifying the least or less time value, the system would maintain the overlapping trip portion as the full toll route.

[0276] A similar analysis is done for the routes on the weekend at 4:00am. Because there is likely little to no traffic at that time of the day / week, the full non-toll route is the route with the least time, the least cost, least toll / time ratio, and best time value (as it costs nothing but saves 3 min). It should also be appreciated that in some instances, the system also is configured to optimize for a total overall cost for the entire trip, not just the total toll cost for that portion of the trip being modified. Optimizations can also be made for- Page 64 - Docket No. 3400.408AWOdifferent times of the day, days of the week, considering the different traffic conditions that exist at those times.

[0277] Attention will now be directed to Figs. 28-30, which illustrate various examples of different criteria, including different metrics, by which to optimize for the selection of the preferred route. It should be appreciated that, as described above, the different criteria or metrics can be determined using historical data, real-time data, predicted data, or a combination thereof.

[0278] Fig. 28 shows a plurality of optimization metrics 2802, including time 2804, toll cost 2806, and total cost 2808. As described previously, the preferred route may be selected from the different possible mixed routes (and / or fully tolled or fully non-tolled routes) based on one or more criteria that yield an improved net toll value. For example, the selection of the preferred route may be based on which possible route results in the lowest trip duration (e.g., time 2804), based on the lowest toll costs (e.g., toll cost 2806), a lowest total cost 2808, other optimization factor 2809, or a combination thereof (e.g., a route that has both the lowest time and lowest toll cost or lowest total cost).

[0279] The total cost of the route may include other costs (e.g., other cost 2810), including fuel 2812, vehicle maintenance 2814 (based on a depreciation calculation, wear & tear calculation, or other actual maintenance fees), if there is an on-time delivery bonus that will be paid to the company for an on-time delivery (e.g., on-time delivery bonus 2816) or conversely, a late delivery penalty that will cost the company if a delivery is made late (e.g., late delivery penalty 2818), driver’s regular or overtime pay (e.g., driver pay 2820), or costs associated with using a toll route management software (e.g., toll route management 2822). Additionally, there may be vehicle lease costs 2824 or other costs 2826 associated with the total cost for the trip, portion of the trip (e.g., overlapping trip portion), or an individual segment of the trip (e.g., segment Tl).

[0280] On top of toll fees, certain routes may incur different costs associated with the aforementioned factors. For example, some routes may have increased or decreased fuel consumption or may result in more or less vehicle maintenance. The inclusion of some routes may decrease the time of the route so that the driver can complete a delivery on- time, even though the route may cost more in toll fees or other fees. Thus, the preferred route would be chosen based on whether the on-time delivery fee would offset the additional toll fees, or if it would be cheaper to deliver the goods a few minutes late and avoid the excessive toll fees. In a similar consideration, the inclusion of an alternate route- Page 65 - Docket No. 3400.408AWOmay result in a late-delivery penalty that may cost more than the money saved by not taking the tolled route portion.

[0281] The system is able to provide analytics data on each of these metrics, including allowing a user to select which metrics to include in the decision-making process for which route to select. These additional costs or total costs may play a more prominent role or be a secondary decision-making step when the preferred route is not as obvious (e.g., there is not a route that is both saving time and money). Additionally, there may be scenarios where a possible mixed route will result in saved time and saved toll costs but may result in an overall total cost or time increase.

[0282] As a default, the system will search for a route that reduces trip time, toll costs, and an overall cost across multiple trips taken by multiple vehicles. However, as described before, if no possible routes are available for reducing all three metrics (i.e., time, toll cost, and total cost), the system is able to be configured to optimize for one or two of the metrics in order to select the preferred route option. In some instances, the original trip route may be the preferred route option. However, but undergoing the process for analyzing across all possible routes, a customer is able to have increased confidence in their current route selection.

[0283] Attention will now be directed to Fig. 29, which illustrates an example of additional criteria, including constraints, by which to modify the selection of the preferred route. Fig. 29 shows various constraints 2902 that can be used to further modify the selection of the preferred route. For example, some constraints 2902 include a maximum time 2904 of the trip, a maximum toll cost 2906, a maximum toll -time ratio or threshold 2908 (see toll / time ratio Fig. 27), a maximum extension of time or minimum reduction of time (2910), a maximum cost of time saved 2914, or maximum cost / time saved 2914 (see time value, Fig. 27).

[0284] In some instances, certain trips must remain under a certain time limit and cannot exceed a maximum time 2904 associated with the overall trip. Similarly, the company may set a maximum toll cost 2906 for a trip, wherein the system selects a route that does not exceed the maximum toll cost. In some instances, the system is set to base or modify the selection of the preferred route based on not exceeding a maximum toll -time threshold, which is determined by the total toll cost versus the total time of the trip. Additionally, or alternatively, the system can be configured to select or modify the selection of a preferred route based on not exceeding a maximum extension of time relative to a current historical or predicted trip time.- Page 66 - Docket No. 3400.408AWO

[0285] Additionally, or alternatively, there may certain time deadlines that must be met, including delivery deadlines 2916. There may also be different company policies 2918 that drivers or vehicles must follow. For example, some companies may set route restrictions including no-go zones or exclusion zones 2922, restricted driving maneuvers such as no unprotected left-hand turns 2924, or a maximum time or distance between rest stops 2926 for drivers to take voluntary or mandatory breaks (i.e., based on state or federal law). Exclusion zones 2922 are geographic zones or areas that drivers are not allowed to drive their vehicles. These exclusion zones 2922 may also be time periods that drivers are not allowed to drive during a particular day. Along with unprotected left-hand turns 2924, there may be additional prohibitions against certain types of driving, such as maximum speed limits, maximum terrain grading, maximum lanes to cross for merging, or other driving factor that may be associated with higher risks or just based on company policy.

[0286] Each of these different constraints can be used as filters to filter out different segments prior, during, or after the generation of the possible mixed routes. For example, each alternate route segment that is identified for a current route segment, the alternate route is segment is analyzed to ensure that it does not violate one of the aforementioned constraints. The system is customizable to be able to determine what constraints are included, if they are included, in the alternate route generation and selection.

[0287] Attention will now be directed to Fig. 30, which illustrates an example of a plurality of other factors that can be used to modify the selection of the preferred route. Fig. 30 shows other factors 3002, including distance 3004, weather conditions 3006, accident road rating 3008, area crime rating 3010, or another factor. For example, the system can take into consideration a total distance of the trip and factor in a maximum distance threshold. Additionally, or alternatively, the system may route vehicles based on historical, current, or predicted weather conditions 3006, including routing away from storms and inclement weather. Weather conditions may also be used in conjunction with other constraints such as if there is inclement weather, the system could be configured to avoid terrain grading over a certain grading, where risk of accident may be increased due to slick road conditions. Systems are also configurable to avoid roads with high percentages of accidents (e.g., accident road ratings 3008) or avoid geographic areas associated with high crime ratings 3010.

[0288] Attention will now be directed to Fig 31, which illustrates an example of a user interface for facilitating dynamic route management. In some instances, value analytics user interface 3102 is representative of the user interface that is displayed when value- Page 67 - Docket No. 3400.408AWOanalytics 616 is selected. As shown in Fig. 31, value analytics user interface 3102 is shown having a plurality of selectable icons or buttons that are configured to perform various functions and display corresponding data. For example, when View Current Routes 3104 is selected, the map visualization 3114 will display a set of trips and their current routes along the infrastructure network and the data visualization 3116 will display the day / time corresponding to the set of trips, the time, the toll cost, and total cost, and any other metrics available to be shown about the current routes.

[0289] When the Select Optimization Metric 3106 is selected, the system prompts the user to select one or more optimization metrics by which to analyze the current routes against possible alternate routes to determine if the current routes should be modified accordingly. The Customize Other Constraints / F actors 3108 allows for users to further define and / or customize the criteria by which the current routes will be analyzed and / or modified. Once the user has selected the optimization metric and defined any other customizations, by selecting the Find New Recommended Routes 3110 button will update the map visualization to show any alternate routes that are available and meet the optimization metrics and other customized constraints / factors.

[0290] The user is then able to select and / or confirm the automatically selected system recommended route (whether that be to maintain the current route, replace the current route, or modify the current route). Once the selection is confirmed, the Analyze Savings 3112 button can be used to update the data visualization 3116 to show all of the different savings that will be realized when the new recommended route is implemented into the set or subset of trips.EXAMPLE METHODS: ROUTE MANAGEMENT

[0291] Attention will now be directed to Fig. 32, which illustrates a process flow diagram comprising a plurality of acts (act 3210, act 3220, act 3230, act 3240, act 3250, act 3260, act 3270), act 3280, and act 3290) associated with a method 3200 for dynamically generating and managing routes for a vehicle fleet.

[0292] A first illustrated act is provided for accessing a plurality of trip data structures that identify different starting and ending locations of a corresponding plurality of trips (e.g., Trip 1, Trip 2, and Trip 3 associated with Figs. 23 A-23C) associated with traversable road infrastructures (act 3210). After accessing the trip data structures, systems identify an overlapping trip portion (e.g., overlapping trip portion 2302) that is included within each of the plurality of trips and that includes a common first location and a common second location within each of the plurality of trips (act 3220). By identifying an overlapping trip- Page 68 - Docket No. 3400.408AWOportion, the system is able to analyze alternate route segments (e.g., alternate route segments illustrated in Fig. 23B) that will be applicable to a plurality of trips, instead of a single trip. This provides the basis for compounding value adds across all trips, instead of the single trip. Systems then divide the overlapping trip portion into a plurality of route segments (e.g., segmented toll route 2414) (act 3230).

[0293] For each route segment of the plurality of route segments, systems identify one or more alternate segments (e.g., segmented non-toll route 2518) (act 3240). Subsequently, systems generate a plurality of route combinations (e.g., mixed route combinations illustrated in Fig. 25) (act 3250). Each route combination (e.g., mixed route 2516) of the plurality of route combination comprises at least one route segment (e.g., Segment Tl) and at least one alternate segment (e.g., Segment N2). Additionally, each route combination extends between the common first location and the common second location associated with the overlapping trip portion. By identifying alternate segments, the system is able to generate and analyze a more diverse and comprehensive set of route combinations.

[0294] The system then determines a route valuation (e.g., time or toll cost associated with Fig. 26, and / or toll / time ratio or time value associated with Fig. 27) for each route combination (act 3260) and selects a preferred route combination (e.g., alternate route 2308, see Fig. 23C) from the plurality of route combinations (act 3270). This selection is performed by comparing the route valuation for each route combination against one or more route criteria (e.g., optimization 2802, constraints 2902, or other factors 3002). By evaluating each route combination, the system is able to determine if the current trip route, which includes the overlapping trip portion, should be maintained, replaced, or modified based on comparing the overlapping trip portion with the different route combinations.

[0295] After selecting the preferred route combination, the system modifies each of the plurality of trip data structures by replacing the overlapping trip portion with the preferred route combination within each of the plurality of trip data structures (act 3280).

[0296] A new trip route is then generated for each of the modified trip data structures (act 3290). This new trip route can then be displayed concurrently on a common user interface (see Fig. 23C and Fig. 31, map visualization 3114). By generating a new trip route for all of the modified trip data structures, the system is able to achieve compounded savings (see Data Visualization 3116), in terms of time, money, or a combination thereof, not just for a single trip, but for all trips that originally comprise the overlapping trip portion.- Page 69 - Docket No. 3400.408AWO

[0297] In some instances, the route valuation is determined for the route combination as a whole. Additionally, or alternatively, the route valuation is based on a plurality of individual segment valuations corresponding to the different route segments and alternate segments included in the route combination. In such instances, systems determine a segment valuation for each route segment of the plurality of route segments and any alternate segments identified to correspond to the plurality of route segments. In some instances, to reduce computational cost and increase efficiency, only the alternate segment with the highest segment valuation is considered as an alternate route segment for the corresponding route segment when generating the different route combinations.

[0298] Alternatively, only the alternate segments with higher segment valuations than the corresponding route segment are considered as alternate route segments for the corresponding route segment when generating the different route combinations. This further improves the route combination generation process by limiting the system to selecting only alternate segments that have the higher segment valuation, as some alternate segments may have a lower segment valuation than the corresponding route segment.

[0299] As described above, regarding the selection of the preferred route combination, the system compares the different route valuations against one or more criteria (see Figs. 28-30). There are many different criteria that can be used to aid and facilitate this selection. In some instances, the one or more criteria includes an optimization factor, such as optimizing for time, optimizing for money (toll cost or total cost), or a combination thereof (see Fig. 28). In some instances, the system determines a time value (i.e., toll cost per time saved, or total cost per time saved), such that the preferred route combination is associated with an improved time value as compared to the overlapping trip portion or other route combinations that were generated. In some instances, the system sets a time value threshold and filters out any route combinations that do not meet the time value threshold.

[0300] When the system optimizes for time, the preferred route combination is selected because the system has determined that it has the lowest time duration of any possible route combination, or at least a lower time duration than the current overlapping trip portion. By including a preferred route combination with a lower or lowest time duration, the overall time duration for every trip is reduced accordingly. To facilitate being able to optimize for reduced time duration, the system determines a time duration for each route segment and each alternate segment included in a route combination. The time durations can be determined based on historical time data, real-time data, and / or predicted time data.- Page 70 - Docket No. 3400.408AWO

[0301] When the system optimizes for toll cost, such that the preferred route combination is route combination associated with a lowest toll cost, the method further comprising identifying one or more tolled segments in the route combination. It should be noted that any of the route segments or alternate segments may be a tolled segment. The system then determines a toll cost for the one or more tolled segments and aggregates the toll costs for any identified tolled segments included in the route combination. These aggregated toll costs represent the toll cost for the route combination. This process is performed for every segment in every route combination that is generated.

[0302] In some instances, the system optimizes the different trips based on reducing a total cost, such that the preferred route combination is a route combination associated with a lowest total cost as compared to other route combinations and the overlapping trip portion or, alternatively, a lower total cost than the overlapping trip portion. In such instances where the system optimizes for total cost, the system determines a total cost for each route segment and each alternate segment in the route combination and aggregates the total costs to determine an overall total cost for the route combination. This is done for every segment in every route combination that is generated.

[0303] The total costs include the toll cost and one or more additional costs, such as fuel costs, vehicle maintenance costs, delivery bonuses and penalties, driver pay, route management costs, or other costs (see Fig. 28).

[0304] Attention will now be directed to Fig. 33 which illustrates a process flow diagram comprising a plurality of acts (act 3310, act 3320, act 3330, act 3340, act 3350, act 3360, act 3370, act 3380, and act 3390) associated with an alternate method for dynamically generating and managing routes for a vehicle fleet. It should be appreciated that act 3310 is representative of act 3210, act 3320 is representative of act 3220, act 3330 is representative of act 3230, act 3340 is representative of act 3240, act 3350 is representative of act 3250, act 3380 is representative of act 3280 and act 3390 is representative of act 3290, such that each of the aforementioned acts of Fig. 33 are associated with the descriptions and technical benefits of the representative acts illustrated in Fig. 32. Notably, act 3360 and act 3370 are modifications to the method illustrated in Fig. 32. Thus, the following description is focused on the integration of act 3360 and act 3370 into method 3300.

[0305] Thus, after generating the plurality of route combinations, the systems generate a filtered route combination set by filtering the plurality of route combinations based on one or more route constraints (act 3360). By filtering the set of route combinations, the- Page 71 - Docket No. 3400.408AWOsystem reduces the computational expense by not evaluating any route combinations that would not be acceptable replacements to the overlapping trip portion based on user (i.e., customer or fleet manager) constraints.

[0306] The system then identified a preferred route combination from the filter route combination set (act 3380). The identification and selection of the preferred route combination is made faster and ensures a higher quality selection from the different route combinations because the filtered route combination set comprises only those route combinations that meet the constraints.

[0307] This filtering process is achieved, in some instances, by determining a route valuation threshold based on a maximum cost of time that is saved by including a particular route combination in a new trip route. The system then filters out one or more route combinations by discarding any route combinations that would force the new trip route to exceed the route valuation threshold.

[0308] The constraints can comprise any number of factors, metrics, criteria, or other constraint definitions (see Fig. 29). For example, the constraints comprise one or more of the following: a maximum route time, a maximum toll cost, a maximum total cost, a delivery deadline, or a company policy. Some example company policies include an exclusion zone, restricted driving maneuvers (e.g., unprotected left-hand turns), or a maximum time between rest stops. The filtering can also be done based on the optimization metrics.

[0309] Additionally, the computational expense of identifying improved routes for the different trips can be further reduced by filtering the alternate segments based on the different constraints (or optimization metrics). For example, prior to generating the plurality of route combinations, the system filters the plurality of alternate segments by discarding any alternate segments that fall outside the constraints or do not serve to optimize the overall trip based on a specified optimization metric. The system is able to generate a filtered set of alternate segments, wherein the plurality of route combinations is generated from the plurality of route segments and the filtered set of alternate segments.

[0310] In some instances, the system also analyzes and filters the route segments associated with the overlapping trip portion in case any current route segments do not meet the constraints. The one or more segment constraints include one or more of the following: a maximum segment time, a maximum segment toll cost, a maximum segment total cost, other constraints, or a combination thereof.- Page 72 - Docket No. 3400.408AWO

[0311] Attention will now be directed to Fig. 34, which illustrates a process flow diagram comprising a plurality of acts (act 3410, act 3420, act 3430, act 3440, act 3450, act 3460, act 3470, and act 3480) associated with a method 3400 for generating and modifying user interfaces (e.g., value analytics user interface 3102) that facilitate improved route management. In particular, method 3400 is associated with improved driver user interfaces for real-time route management.

[0312] A first illustrated act is provided for identifying a trip data structure that identifies a corresponding trip (e.g., Trip 1, Fig. 23A) comprising a first location and a second location (act 3410). The system then divides the trip into a plurality of route segments (e.g., segmented toll route 2414) (act 3420) and for each route segment of the plurality of route segments, identifies one or more alternate segments (e.g., segmented non-toll route 2518) (act 3430). By identifying alternate route segments, the system will be able to compare the original route against alternative routes (see Fig. 23B) to perform improved and better-informed routing decisions.

[0313] The system generates a segment valuation (e.g., time, toll cost, total cost, toll / time, or time value; see Figs. 26-27) for each route segment of the plurality of route segments and for any alternate segments (act 3440). The system evaluates each segment based on various different criteria (see Figs. 28-30), including optimizing for time, money, or a combination of both (e.g., time value). In some instances, the system also is able to filter out segments based on various user-defined constraints, such as delivery deadlines, prohibited driving maneuvers, or any other constraint or factor described herein.

[0314] Subsequently, the system identifies at least one alternate segment that is associated with a higher segment valuation than its corresponding route segment (act 3450). The system then identifies one or more toll gantries associated with the corresponding route segment and labeling the one or more toll gantries (e.g., gantry G4 - gantry G7 associated with the route segment that corresponds to alternate route segment 2308) as exclusion zones (act 3460). It should be appreciated that the system, in some instances, identifies multiple alternate segments that have a higher segment valuation than the corresponding route segment, in which case the system modifies the trip data structure to include the alternate segment with the highest segment valuation.

[0315] The system modifies the trip data structure with instructions to avoid the exclusions zones (act 3470) and transmits the updated trip data structure to a vehicle routing device in communication with the system (act 3480). In some instances, the trip data structure is further modified by replacing the corresponding route segment with the- Page 73 - Docket No. 3400.408AWOalternate route segment associated with the higher segment valuation. In this manner, the vehicle routing device is able to generate a route, in real-time, for an imminent trip that will yield a higher net toll value.

[0316] In view of the foregoing, it will be appreciated that the disclosed embodiments provide many technical benefits over conventional systems and methods for improved route management. For example, the disclosed embodiments provide dynamic and highly customizable route management based on historical, real-time, and / or predictive data to optimize savings across an entire vehicle fleet taking multiple different trips. The system is beneficially able to detect an overlapping trip portion between trips that have different starting and ending locations, to provide compounded savings across multiple trips.

[0317] It should be appreciated that any of the disclosed embodiments related to telematics tracking, correlated trip datasets, calculating net present toll values, identifying toll bill errors, identifying pre-violations, identifying vehicle fraud and abuse, assigning tags, and other pre-trip, en route, and post-trip analytics, are also applicable to route management.

[0318] For example, telematics tracking, toll agency databases, and correlated trip datasets are used to determine or predict toll transactions that are incurred along a toll route. Additionally, net present toll values can be generated for vehicle companies and customers. The disclosed embodiments related to route management also achieve technical benefits associated with toll bill error detection and mitigation, as well as being able to identify and alert customers and fleet companies about pre-violations or re-occurring violations. Disclosed systems are also beneficial in identifying and preventing vehicle fraud and abuse. Vehicle fleet companies will also benefit from the systems and methods described herein for assigning and distributing vehicle tags.Example Computer Systems

[0319] Embodiments of the present invention may comprise or utilize a specialpurpose or general-purpose computer (e.g., computing system 310) including computer hardware, as discussed in greater detail below. Embodiments within the scope of the present invention also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures, which are executable for configuring the disclosed systems to implement the disclosed functionality. Such computer-readable media can be any available media that can be accessed by a general - purpose or special-purpose computer system.- Page 74 - Docket No. 3400.408AWO

[0320] Computer-readable media (e.g., hardware storage device(s) 340 of Fig. 3) that store computer-executable instructions (e.g., computer-readable instructions 318 of Fig. 3) are physical hardware storage media / devices that exclude transmission media. Computer- readable media that carry computer-executable instructions or computer-readable instructions (e.g., computer-readable instructions 318) in one or more carrier waves or signals are transmission media. Thus, by way of example, and not limitation, embodiments of the invention can comprise at least two distinctly different kinds of computer -readable media: physical computer-readable storage media / devices and transmission computer- readable media.

[0321] Physical computer-readable storage media / devices are hardware and include RAM, ROM, EEPROM, CD-ROM or other optical disk storage (such as CDs, DVDs, etc ), magnetic disk storage or other magnetic storage devices, or any other hardware which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.

[0322] A “network” (e.g., network 330 of Fig. 3) is defined as one or more data links that enable the transport of electronic data between computer systems and / or modules and / or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmission media can include a network and / or data links that can be used to carry, or desired program code means in the form of computer-executable instructions or data structures, and which can be accessed by a general purpose or special purpose computer. Combinations of the above are also included within the scope of computer-readable media.

[0323] Further, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission computer-readable media to physical computer-readable storage media (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a “NIC”), and then eventually transferred to computer system RAM and / or to less volatile computer-readable physical storage media at a computer system. Thus, computer-readable physical storage media can be included in computer system components that also (or even primarily) utilize transmission media.- Page 75 - Docket No. 3400.408AWO

[0324] Computer-executable instructions comprise, for example, instructions and data that cause a general-purpose computer, special-purpose computer, or special-purpose processing device to perform a certain function or group of functions. The computerexecutable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0325] Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, switches, and the like. The invention may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.

[0326] Alternatively, or in addition, the functionality described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that can be used include Field-programmable Gate Arrays (FPGAs), Program-specific Integrated Circuits (ASICs), Program-specific Standard Products (ASSPs), System-on-a-chip systems (SOCs), Complex Programmable Logic Devices (CPLDs), etc.

[0327] The present invention may be embodied in other specific forms without departing from its essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.- Page 76 - Docket No. 3400.408AWO

Claims

CLAIMSWhat is claimed is:

1. A method for performing route management, the method comprising: accessing a plurality of trip data structures that identify different starting and ending locations of a corresponding plurality of trips associated with traversable road infrastructures; identifying an overlapping trip portion that is included within each of the plurality of trips and that includes a common first location and a common second location within each of the plurality of trips; dividing the overlapping trip portion into a plurality of route segments; identifying, for each route segment of the plurality of route segments, one or more alternate segments; generating a plurality of route combinations, wherein each route combination of the plurality of route combinations comprises at least one route segment and at least one alternate segment, and wherein each route combination of the plurality of route combinations extends between the common first location and the common second location; determining a route valuation for each route combination of the plurality of route combinations; selecting a preferred route combination based on comparing the route valuation for each route combination against one or more route criteria; modifying each of the plurality of trip data structures by replacing the overlapping trip portion with the preferred route combination within each of the plurality of trip data structures; and generating a new trip route for each of the modified trip data structures.

2. The method of claim 1, further comprising: displaying the new trip route for each of the modified trip data structures concurrently on a common user interface.

3. The method of claim 1, further comprising: determining a segment valuation for each route segment of the plurality of route segments and any alternate segments identified to correspond to the plurality of route segments.- Page 77 - Docket No. 3400.408AWO4. The method of claim 3, wherein the route combination valuation for a particular route combination is based on a plurality of segment valuations corresponding to one or more route segments and one or more alternate segments that form the particular route combination.

5. The method of claim 1, wherein the one or more criteria includes optimizing for time, such that the preferred route combination is a route combination associated with a lowest time duration.

6. The method of claim 5, further comprising: determining a time duration for each route segment and each alternate segment included in the route combination.

7. The method of claim 6, wherein determining the time duration is based on one or more of the following: historical time data, real-time data, or predicted time data.

8. The method of claim 1 or 5, wherein the one or more criteria includes optimizing for toll cost, such that the preferred route combination is a route combination associated with a lowest toll cost.

9. The method of claim 8, further comprising: identifying one or more tolled segments included in the route combination; determining a toll cost for the one or more tolled segments included in the route combination; and aggregating the tolls costs for the tolled segments included in the route combination.

10. The method of claim 1 or 5, wherein the one or more criteria includes optimizing for total cost, such that the preferred route combination is a route combination associated with a lowest total cost.

11. The method of claim 10, further comprising:- Page 78 - Docket No. 3400.408AWOdetermining a total cost for each route segment and each alternate segment included in the route combination; and aggregating the total costs for each route segment and each alternate segment included in the route combination.

12. The method of claim 11, wherein the total cost includes a toll cost and one or more of the following: fuel costs, vehicle maintenance costs, on-time delivery bonuses, late delivery penalties, driver pay, or toll route management costs.

13. The method of claim 1, wherein the preferred route combination is a route combination associated with a combination of a lowest time and a lowest toll cost.

14. The method of claim 13, wherein the combination of a lowest time and a lowest toll cost is based on determining a toll cost per time saved for the preferred route combination as compared to an original route combination included in the trip.

15. A method for dynamically managing routes of a vehicle fleet, the method comprising: accessing a plurality of trip data structures that identify different starting and ending locations of a corresponding plurality of trips associated with traversable road infrastructure; identifying an overlapping trip portion that is included within each of the plurality of trips and that includes a common first location and a common second location within each of the plurality of trips; dividing the overlapping trip portion into a plurality of route segments; identifying, for each route segment of the plurality of route segments, one or more alternate segments; generating a plurality of route combinations that comprises at least one route segment selected from the plurality of route segments and at least one alternate segment from the plurality of alternate segments and wherein each route combination of the plurality of route combinations extends between the first location and the second location; generating a filtered route combination set by filtering the plurality of route combinations based on one or more route constraints;- Page 79 - Docket No. 3400.408AWOidentifying a preferred route combination from the filtered route combination set; modifying each of the plurality of trip data structures by replacing the overlapping trip portion with the preferred route combination within each of the plurality of trip data structures; and generating a new trip route for each of the modified trip data structures.

16. The method of claim 15, further comprising: determining a route valuation threshold based on a maximum cost of time saved by including a particular route combination in a new trip route, wherein filtering the plurality of route combinations further includes discarding route combinations that would force a new trip route to exceed the route valuation threshold.

17. The method of claim 15, wherein the route constraints comprise one or more of the following: a maximum route time, a maximum toll cost, a maximum total cost, a delivery deadline, or a company policy.

18. The method of claim 17, wherein a company policy includes one of the following: an exclusion zone, restricted driving maneuvers, or a maximum time between rest stops.

19. The method of claim 15, further comprising: prior to generating the plurality of route combinations, filtering the plurality of alternate segments based on one or more segment constraints; and generating a filtered set of alternate segments, wherein the plurality of route combinations is generated from the plurality of route segments and the filtered set of alternate segments.

20. The method of claim 19, wherein the one or more segment constraints include one or more of the following: a maximum segment time, a maximum segment toll cost, a maximum segment total cost, or a combination thereof.

21. A computing system for dynamically determining routing instructions for vehicle fleets, the system comprising:- Page 80 - Docket No. 3400.408AWOa processor; and a hardware storage system storing executable instructions that are executable to cause the processor to at least: identifying a trip data structure that identifies a corresponding trip comprising a first location and a second location; dividing the trip into a plurality of route segments; identifying, for each route segment of the plurality of route segments, one or more alternate segments; generating a segment valuation for each route segment of the plurality of route segments and for any alternate segments; identifying at least one alternate segment that is associated with a higher segment valuation than its corresponding route segment; identifying one or more toll gantries associated with the corresponding route segment and labeling the one or more toll gantries as exclusion zones; modifying the trip data structure with instructions to avoid the exclusion zones; and transmitting the updated trip data structure to a vehicle routing device in communication with the computing system.- Page 81 - Docket No. 3400.408AWO

Images