DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This is a Final Office Action on the merits. Claims 1-20 are currently pending and are addressed below.
Response to Amendment
1. The amendment filed 11/26/2025 has been entered. Claims 1-20 remain pending in the application. Applicant’s amendments to the claims have overcome each objection previously set forth in the Non-Final Office Action mailed August 13, 2025.
Response to Arguments
2. Regarding the rejection made under 35 USC 101, the Applicant’s amendments and/or arguments with respect to the rejection have been fully considered but are not persuasive. As such, the Examiner maintains the rejected for at least the rationale noted below:
The Applicant argues on page 11 of the remarks that the amended claim 1 (and similarly 13 and 17) recites a system to access digital map database, extract specific map features (such as a terrain or infrastructure attributes supported), and utilize a machine learning model to learn complex relationships between those features and time deviations in real-time which is computationally intensive and impossible for a human to perform mentally. The Examiner respectfully disagrees. A person can certainly mentally learn from observed map features (which can be two features) and real-time deviation of a truck. For example, a person could mentally learn from observing map features from a map and if the truck stopped or missed the pit stops that can cause additional delays. Applicant further argues that the computations are beyond the human mind due to the volume of map data, however, broadly interpreted, the map data can be two or three features which can certainly be done in the mind.
Applicant states that the claims are integrated into a practical application by providing a technical solution. Applicant further states that the amended claims provide a technical solution (using machine learning) to learn “relationships between map features obtained from a geographic database and deviations in the real-time ETA scorecard” then “determining one or more predicted events for one or more subsequent monitoring periods based on the learned relationships of the machine learning model”. The Examiner respectfully disagrees. This limitation, as drafted, is a simple process that, under its broadest reasonable interpretation per the specification, covers performance of the limitation in the mind, but for the limitation that a processor and a machine learning model can be programed to perform the task. For example, a person could mentally predict that the route will require one more pit stop to total three pit stops before arriving at the destination based on learned data. The mere nominal recitation of using a machine learning model does not take the claim limitations out of the mental process grouping. See 35 USC 101 rejection below for further explanation and clarifications.
Regarding the rejection made under 35 USC 103, the Applicant’s amendments and arguments have been fully considered but are moot because of the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 101
3. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
4. Claims 1-20 is/are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more.
101 Analysis – Step 1 - Statutory Category – Yes
Claim 1 is directed to a method (i.e., a process). Claim 13 is directed to an apparatus (i.e., a machine). Claim 17 is directed to a medium (i.e., a manufacture)
Therefore, claims 1, 13, and 17 are within at least one of the four statutory categories. MPEP 2106.03.
101 Analysis – Step 2A, Prong I - Judicial Exception – Yes
Regarding Prong I of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether they recite subject matter that falls within one of the follow groups of
abstract ideas: a) mathematical concepts, b) certain methods of organizing human activity, and/or c) mental processes.
Independent claims 1, 13, and 17 includes limitations that recite an abstract idea (emphasized below) and will be used as a representative claim for the remainder of the 101 rejection.
Independent claims 1 (and similarly 13 and 17) includes the recitation below:
computing an original estimated time of arrival (ETA) for a commercial vehicle traveling on a route for a transportation and logistics (T&L) industry trip, wherein the T&L industry trip is subject to one or more required events during the route, and wherein the original ETA is computed based on one or more pre-trip predicted events that are predicted based on an initial set of assumptions and the one or more required events;
processing the real-time location trace data to determine one or more actual events of the commercial vehicle, the driver, or a combination occurring during the monitoring period;
processing the real-time ETA scorecard using a machine learning model to learn relationships between map features obtained from a geographic database and deviations in the real-time ETA scorecard;
determining one or more predicted events for one or more subsequent monitoring periods based on the learned relationships of the machine learning model;
determining an updated ETA for the route based on the one or more predicted events;
The examiner submits that the foregoing bolded limitation(s) constitute a “mental process” because under its broadest reasonable interpretation, the claim covers performance of the limitation in the human mind. For example, “computing…”, “processing…”, and “determining…” in the context of this claim encompasses a person looking at data collected and making a simple judgement on the data collected.
The claims recite computing an original estimated time of arrival (ETA) for a commercial vehicle traveling on a route for a transportation and logistics (T&L) industry trip, wherein the T&L industry trip is subject to one or more required events during the route, and wherein the original ETA is computed based on one or more pre-trip predicted events that are predicted based on an initial set of assumptions and the one or more required events. This limitation, as drafted, is a simple process that, under its broadest reasonable interpretation per the specification, covers performance of the limitation in the mind, but for the limitation that a processor can be programed to perform the task. That is, other than reciting “a processor” in claims 13 and 17, nothing in the claim precludes the element being done in the mind. For example, a person could look at a map and mentally calculate an estimated time for a vehicle to arrive is 5 hours based on the assumption that there is three pit stops to refuel.
The claims recite processing the real-time location trace data to determine one or more actual events of the commercial vehicle, the driver, or a combination occurring during the monitoring period. This limitation, as drafted, is a simple process that, under its broadest reasonable interpretation per the specification, covers performance of the limitation in the mind, but for the limitation that a processor can be programed to perform the task. That is, other than reciting “a processor” in claims 13 and 17, nothing in the claim precludes the element being done in the mind. For example, a person could look at a map and see the current location of the truck and mentally determine that the truck is delayed by 30 min. after making two pit stops to refuel.
The claims recite processing the real-time ETA scorecard using a machine learning model to learn relationships between map features obtained from a geographic database and deviations in the real-time ETA scorecard. This limitation, as drafted, is a simple process that, under its broadest reasonable interpretation per the specification, covers performance of the limitation in the mind, but for the limitation that a processor and a machine learning model can be programed to perform the task. That is, other than reciting “machine learning model” and “a processor” in claims 13 and 17, nothing in the claim precludes the element being done in the mind. For example, a person could mentally learn from observing two map features from a map and if the truck stopped or missed the pit stops that can cause additional delays. The mere nominal recitation of using a machine learning model does not take the claim limitations out of the mental process grouping.
The claims recite determining one or more predicted events for one or more subsequent monitoring periods based on the learned relationships of the machine learning model. This limitation, as drafted, is a simple process that, under its broadest reasonable interpretation per the specification, covers performance of the limitation in the mind, but for the limitation that a processor and a machine learning model can be programed to perform the task. That is, other than reciting “machine learning model” and “a processor” in claims 13 and 17, nothing in the claim precludes the element being done in the mind. For example, a person could mentally predict that the route will require one more pit stop to total three pit stops before arriving at the destination based on learned data. The mere nominal recitation of using a machine learning model does not take the claim limitations out of the mental process grouping.
The claims recite determining an updated ETA for the route based on the one or more predicted events. This limitation, as drafted, is a simple process that, under its broadest reasonable interpretation per the specification, covers performance of the limitation in the mind, but for the limitation that a processor can be programed to perform the task. That is, other than reciting “a processor” in claims 13 and 17, nothing in the claim precludes the element being done in the mind. For example, a person could mentally determine that the route takes 5 hours and 30 min. and require three pit stops to refuel.
Examiner would also note MPEP 2106.04 (a) (III) A discloses that examples of mental processes include observation evaluations and judgements, citing Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016). Here, the integrating and generating are forms of making evaluations and judgements based on observations (data collected). Accordingly, the claim recites at least one abstract idea.
101 Analysis – Step 2A, Prong II - Practical Application – No
Regarding Prong II of the Step 2A analysis in the 2019 PEG, the claims are to be analyzed to determine whether the claim, as a whole, integrates the abstract into a practical application. As noted in the 2019 PEG, it must be determined whether any additional elements in the claim beyond the abstract idea integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.”
In the present case, the additional limitations beyond the above-noted abstract idea are as follows (where the underlined portions are the “additional limitations” while the bolded portions continue to represent the “abstract idea”):
A method comprising:
computing an original estimated time of arrival (ETA) for a commercial vehicle traveling on a route for a transportation and logistics (T&L) industry trip, wherein the T&L industry trip is subject to one or more required events during the route, and wherein the original ETA is computed based on one or more pre-trip predicted events that are predicted based on an initial set of assumptions and the one or more required events;
monitoring real-time location trace data collected from one or more sensors of the commercial vehicle on the route during a monitoring period;
processing the real-time location trace data to determine one or more actual events of the commercial vehicle, the driver, or a combination occurring during the monitoring period; generating a real-time ETA scorecard that compares the one or more actual events to the one or more required events, the one or more pre-trip predicted events, one or more prior events determined for one or more previous monitoring periods, or a combination thereof;
processing the real-time ETA scorecard using a machine learning model to learn relationships between map features obtained from a geographic database and deviations in the real-time ETA scorecard;
determining one or more predicted events for one or more subsequent monitoring periods based on the learned relationships of the machine learning model;
determining an updated ETA for the route based on the one or more predicted events; and
providing the updated ETA, the real-time ETA scorecard, or a combination thereof as an output.
For the following reason(s), the examiner submits that the above identified additional limitations do not integrate the above-noted abstract idea into a practical application.
Regarding the additional limitations of “monitoring real-time location trace data collected from one or more sensors of the commercial vehicle on the route during a monitoring period…”, “generating a real-time ETA scorecard that compares the one or more actual events to the one or more required events, the one or more pre-trip predicted events, one or more prior events determined for one or more previous monitoring periods, or a combination thereof…”, and “providing the updated ETA, the real-time ETA scorecard, or a combination thereof as an output…”, the examiner submits that these limitations are insignificant extra-solution activities that merely use a computer (i.e., a processor under the broadest reasonable interpretation) to perform the process. In particular, the “monitoring real-time location trace data collected from one or more sensors of the commercial vehicle on the route during a monitoring period…” step is recited at a high level of generality (i.e., as a general means of gathering of measurement data for use in the determining steps), and amounts to mere data gathering, which is a form of insignificant extra-solution activity. The “generating a real-time ETA scorecard…”, and “providing the updated ETA…” steps are also recited at a high level of generality (i.e. as a general means of displaying the updated time of arrival results from the determination step), and amounts to mere post solution displaying, which is a form of insignificant extra-solution activity, see MPEP 2106.05(g).
The additional elements is/are generic computer components recited at a high level of generality for performing the insignificant extra solution activity steps of mere data gathering and data sending.
Thus, taken alone, the additional elements do not integrate the abstract idea into a practical application. Further, looking at the additional limitation(s) as an ordered combination or as a whole, the limitation(s) add nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, apply or use the above-noted judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, implement/use the above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is not more than a drafting effort designed to monopolize the exception (MPEP § 2106.05). Accordingly, the additional limitation(s) do/does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
101 Analysis – Step 2B - Inventive Concept – No
Regarding Step 2B of the 2019 PEG, representative independent claims 1, 13, and 17 do not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a computer and processor to perform the recited abstract idea amounts to nothing more than applying the exception using a generic computer component. Generally applying an exception using a generic computer component cannot provide an inventive concept. And as discussed above, the additional limitations of “monitoring real-time location trace data…”, “generating a real-time ETA scorecard…”, and “providing the updated ETA…”, the examiner submits that these limitations are insignificant extra-solution activities.
Further, a conclusion that an additional element is insignificant extra-solution activity in Step 2A should be re-evaluated in Step 2B to determine if they are more than what is well-understood, routine, conventional activity in the field. The additional limitation of “monitoring real-time location trace data…”, is well-understood, routine, and conventional activities in the field. The specification and background therein do not provide any indication that the computer (processor) is anything other than possible generic and conventional computer components. MPEP 2106.05(d)(II), and the cases cited therein, including Intellectual Ventures I, LLC v. Symantec Corp., 838 F.3d 1307, 1321 (Fed. Cir. 2016), TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610 (Fed. Cir. 2016), and OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363 (Fed. Cir. 2015), indicate that mere collection or receipt of data over a network is a well‐understood, routine, and conventional function when it is claimed in a merely generic manner (as in here), see MPEP 2106.05(g). The additional limitation of “generating a real-time ETA scorecard…”, and “providing the updated ETA…”, are well-understood, routing, and conventionally activities because the Federal Circuit in Trading Techs. Int’l v. IBG LLC, 921 F.3d 1084, 1093 (Fed. Cir. 2019), and Intellectual Ventures I LLC v. Erie Indemnity Co., 850 F.3d 1315, 1331 (Fed. Cir. 2017), for example, indicated that the mere displaying of data is a well understood, routine, and conventional function. Hence, the claims are not patent eligible.
Dependent Claims:
Dependent claims 2-12, 14-16, and 18-20 do not recite any further limitations that cause the claims to be patent eligible. Rather, the limitations of dependent claims are directed toward additional aspects of the judicial exception and/or well-understood, routine and conventional additional elements that do not integrate the judicial exception into a practical application. Therefore, dependent claims 2-12, 14-16, and 18-20 are not patent eligible under the same rationale as provided for in the rejection of claims 1, 13, and 17.
Therefore, claims 1-20 are ineligible under 35 USC §101 as being drawn to an abstract idea without significantly more, and thus are ineligible.
Claim Rejections - 35 USC § 103
5. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
6. Claims 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shaukat et al. (US 20190226862, hereinafter Shaukat) in view of Cirit et al. (US 20230229966, hereinafter Cirit) and in further view of Cova (US 20110050397, hereinafter Cova).
Regarding claim 1, Shaukat teaches a method (see at least 4 and [0055]: “FIG. 4 is a flow chart of an example process 400 for dynamically updating an estimated time of arrival.”) comprising:
computing an original estimated time of arrival (ETA) for a commercial vehicle traveling on a route for a transportation and logistics (T&L) industry trip, wherein the T&L industry trip is subject to one or more required events during the route, and wherein the original ETA is computed based on one or more pre-trip predicted events that are predicted based on an initial set of assumptions and the one or more required events (see at least [0013]: “In some implementations, routing platform 108 can determine an estimated time of arrival for the vehicle at one or more job sites for the driver of the vehicle. For example, based on information identifying a location of the vehicle, a status of the vehicle, a type of job that is to be completed by the driver of the vehicle (e.g., a length of the job), a schedule of availability of equipment that is to be obtained and used by the driver of the vehicle to complete a job, a current traffic condition, a predicted traffic condition, a current weather condition, a predicted weather condition, an availability of another driver and another vehicle to complete one or more jobs for the driver of the vehicle, and/or the like, routing platform 108 can determine the estimated time of arrival for at least one upcoming job.”);
monitoring real-time location trace data collected from one or more sensors of the commercial vehicle on the route during a monitoring period (see at least [0013]: “In some implementations, routing platform 108 can use a heuristic, conditional logic, a machine learning technique, a deep learning technique, a neural network technique, and/or the like to dynamically update the estimated time of arrival and/or automatically track a status of the vehicle and the driver. For example, routing platform 108 can use a heuristic to process input data and determine whether the driver has arrived at a job site.”; [0037]: “External data source 270 includes one or more devices associated with receiving, generating, storing, processing, and/or providing information associated with determining an estimated time of arrival. For example, external data source 270 can include a server identifying a route for a set of vehicles, a schedule for availability of an item (e.g., equipment that is to be used to complete an installation, a service, a repair, and/or the like), a traffic condition, a weather condition, and/or the like. In some implementations, external data source 270 can include one or more sensors, such as one or more traffic sensors, weather sensors, location sensors, and/or the like. In some aspects, external data sources 270 can provide data in real-time or near real-time (e.g., within a threshold period of time of data collection, data acquisition, and/or the like).”; [0040]: “Navigation device data collection module 284 includes one or more computing resources of cloud environment 250 implemented to obtain data from a navigation device, such as a mobile device 205 installed as a telematics device of a vehicle, a global positioning system (GPS) device of a vehicle, and/or the like. In some implementations, navigation device data collection module 284 can obtain data relating to a path (e.g., a set of directions being used by a driver to navigate to a job site), a deviation from a path (e.g., a change from an intended path to an actual path), an estimated time of arrival (e.g., calculated by the navigation device based on a path, a traffic condition, and/or the like), and/or the like. In some implementations, navigation device data collection module 284 can provide the data to data bus 288. For example, navigation device data collection module 284 can provide an update identifying a path of a vehicle.”);
processing the real-time location trace data to determine one or more actual events of the commercial vehicle, the driver, or a combination occurring during the monitoring period (see at least [0012]: “Additionally, or alternatively, routing platform 108 can receive vehicle data from telematics device 104, such as data identifying a location of the vehicle, a speed of the vehicle, a status of the vehicle (e.g., an engine status, vehicle location, vehicle alerts, vehicle sensor readings, vehicle speed, vehicle direction, vehicle geofence proximity, and/or status information from one or more other vehicle sensors of the vehicle), and/or the like.”; [0013]: “In some implementations, routing platform 108 can determine an estimated time of arrival for the vehicle at one or more job sites for the driver of the vehicle. For example, based on information identifying a location of the vehicle, a status of the vehicle, a type of job that is to be completed by the driver of the vehicle (e.g., a length of the job), a schedule of availability of equipment that is to be obtained and used by the driver of the vehicle to complete a job, a current traffic condition, a predicted traffic condition, a current weather condition, a predicted weather condition, an availability of another driver and another vehicle to complete one or more jobs for the driver of the vehicle, and/or the like, routing platform 108 can determine the estimated time of arrival for at least one upcoming job.“);
generating a real-time ETA information that compares the one or more actual events to the one or more required events, the one or more pre-trip predicted events, one or more prior events determined for one or more previous monitoring periods, or a combination thereof (see at least [0038]: “As shown in FIG. 2B, routing platform 260 can include a driver device data collection module 282, a navigation device data collection module 284, one or more other data collection modules 286, a data bus 288, a data repository module 290, an estimated time of arrival (ETA) service module 292, and a data output module 294.”; [0068]: “Similarly, routing platform 260 can automatically determine whether a break will be shortened (e.g., which may relate to a state of an operator, such as a driver) using conditional logic, such as based on whether the break is a mandatory break (e.g., a legally obligated or contractually obligated break), which will not be shortened, or a non-mandatory break, which can be shortened, thereby improving an accuracy of an estimated time of arrival determination relative to another technique that does not distinguish between types of breaks and/or does not account for changes to non-mandatory breaks to ensure timeliness.”);
processing the real-time ETA using machine learning to learn relationships between features obtained from a database and the real-time ETA (see at least Fig. 1A and [0013]: “For example, based on information identifying a location of the vehicle, a status of the vehicle, a type of job that is to be completed by the driver of the vehicle (e.g., a length of the job), a schedule of availability of equipment that is to be obtained and used by the driver of the vehicle to complete a job, a current traffic condition, a predicted traffic condition, a current weather condition, a predicted weather condition, an availability of another driver and another vehicle to complete one or more jobs for the driver of the vehicle, and/or the like, routing platform 108 can determine the estimated time of arrival for at least one upcoming job. In some implementations, routing platform 108 can use a heuristic, conditional logic, a machine learning technique, a deep learning technique, a neural network technique, and/or the like to dynamically update the estimated time of arrival and/or automatically track a status of the vehicle and the driver.”);
determining one or more predicted events for one or more subsequent monitoring periods based on the learned relationships of the machine learning (see at least [0013]: “In some implementations, routing platform 108 can use a heuristic, conditional logic, a machine learning technique, a deep learning technique, a neural network technique, and/or the like to dynamically update the estimated time of arrival and/or automatically track a status of the vehicle and the driver.”; [0068]: “Similarly, routing platform 260 can automatically determine whether a break will be shortened (e.g., which may relate to a state of an operator, such as a driver) using conditional logic, such as based on whether the break is a mandatory break (e.g., a legally obligated or contractually obligated break), which will not be shortened, or a non-mandatory break, which can be shortened, thereby improving an accuracy of an estimated time of arrival determination relative to another technique that does not distinguish between types of breaks and/or does not account for changes to non-mandatory breaks to ensure timeliness.”);
determining an updated ETA for the route based on the one or more predicted events (see at least [0013]: “In some implementations, routing platform 108 can use a heuristic, conditional logic, a machine learning technique, a deep learning technique, a neural network technique, and/or the like to dynamically update the estimated time of arrival and/or automatically track a status of the vehicle and the driver.”; [0064]: “In some implementations, routing platform 260 can update an estimated time of arrival. For example, routing platform 260 can determine, based on a first estimated time of arrival and an alteration to the input data from previously collected input data, a second estimated time of arrival that is different from the first estimated time of arrival. In this way, routing platform 260 dynamically determines an estimated time of arrival to enable enhanced vehicle tracking by a dispatcher, a customer, and/or the like.”; [0068]: “Similarly, routing platform 260 can automatically determine whether a break will be shortened (e.g., which may relate to a state of an operator, such as a driver) using conditional logic, such as based on whether the break is a mandatory break (e.g., a legally obligated or contractually obligated break), which will not be shortened, or a non-mandatory break, which can be shortened, thereby improving an accuracy of an estimated time of arrival determination relative to another technique that does not distinguish between types of breaks and/or does not account for changes to non-mandatory breaks to ensure timeliness.”); and
providing the updated ETA, the real-time ETA information, or a combination thereof as an output (see at least [0014]: “As shown in FIG. 1B, and by reference number 120, routing platform 108 can provide output associated with the route information. As shown by reference number 122, routing platform 108 can provide output identifying an updated route to mobile device 106-1. For example, based on determining an updated estimated time of arrival based on the vehicle arriving at a job site late, a job taking less time than predicted, an item of equipment becoming available for the driver to borrow at an earlier time than expected, an accident causing a change to a traffic condition, a predicted rainstorm resulting in a predicted road closure, and/or the like, routing platform 108 can provide an updated route to the driver to identify an altered driving path for the driver, an altered estimated time of arrival for a job, an altered break schedule, an altered order of jobs, and/or the like. As shown by reference number 124, routing platform 108 can provide output identifying an updated estimated time of arrival to mobile device 106-2. For example, based on determining that the vehicle was 30 minutes late to a job site resulting in a shortened break during the job of 5 minutes less than routed for, and an altered traffic condition when the vehicle departs the job site 25 minutes after routed for, routing platform 108 can provide an estimated time of arrival of 45 minutes after routed for.”).
Shaukat fails to explicitly teach using a machine learning model to learn relationships between map features obtained from a geographic database and deviations in the real-time ETA.
However, Cirit teaches a method and system for predicting an estimated time of arrival of a vehicle that uses a machine learning model to learn relationships between map features obtained from a geographic database and deviations in a real-time ETA (see at least Figs. 1-3 and [0028]: “The machine-learned model 160 (e.g., ETA post-processing model) according to the present disclosure implements a hybrid approach that treats the routing engine 150 ETA as a noisy estimate of the true arrival time. In some embodiments, the machine-learned model 160 may be a deep learning-based model to predict the difference between the routing engine 150 ETA and the observed arrival time. As shown in FIG. 1, the routing APIs 170 may receive an ETA request from an ETA consumer on the ETA consumer system 125. For example, the request may be based on a user request for a vehicle to conduct a trip that includes a first location (e.g., end location of a trip). The routing APIs 170 may also receive corresponding feature data for the trip from the ETA consumer system 125. Based on the request, the routing engine 150 with access to map data 140 and real-time traffic data 145 may compute the predicted ETA for the vehicle to travel from a particular location (e.g., current location or begin location) to the first location.”: [0037]: “The features may be categorized into different categories. For example, the features may be categorized into continuous features 311, categorical features 312, geospatial features 313, calibration features 314, and other features 315.”).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Shaukat to incorporate the teachings of Cirit and provide means to use a machine learning model to learn relationships between map features obtained from a geographic database and deviations in a real-time ETA, with a reasonable expectation of success, in order a refined the ETA using a machine-learned model that takes a plurality of features as input associated with a trip [0004].
The combination of Shaukat and Cirit fails to explicitly teach utilizing a scorecard to report information data.
However, Cova teaches a method and system for generating supply chain management statistics from tracking data that utilizes a scorecard to report information data (see at least [0099]: “In some implementations, the user notification can be a report of the event notification, augmented by details extracted from the enterprise data, for example, if the event notification specifies that a security event has occurred, the system can generate a user notification that indicates that the items in the asset were in an asset for which a security event has occurred that an asset on its way to a particular supplier had a security event, that an asset being used to ship items from or to a particular division of the enterprise had a security event, or that an asset used to ship items associated with a particular product had a security event. In some implementations, the user notification also includes a dynamic estimated time of arrival for the asset, calculated, for example, from the data received about the asset's journey and historical lead time information gathered from past journeys along the same route.”; [0105]: “Examples of supply chain management statistics include, but are not limited to, estimated time of arrival for inventory, lead time, fulfillment risk, demand and supply balance, products inbound, perfect order fill rate, shipment fill rate, on-time shipment rate, on-time arrival rate, amount ordered, amount shipped, amount arrived, inventory in-transit, and carrier and vendor performance scorecards.”; [0113]: “The carrier scorecards indicate the performance of carriers over time. For example, the scorecard can calculate one or more of the statistics described above, such as lead time, for assets carried by a particular carrier and provide the statistics to the end user as an overview of the carrier's effectiveness. Similarly, vendor scorecards can be generated with vendor-specific statistics.”).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Shaukat and Cirit to incorporate the teachings of Cova and provide a scorecard to report information data, with a reasonable expectation of success, in order provide an alternative means of reporting and presenting the information data.
Regarding claim 2, modified Shaukat teaches the limitations of claim 1. Shaukat further teaches wherein the initial set of assumptions is based, at least in part, on prior location trace data for one or more previous commercial trips made by the driver (see at least [0064]: “In some implementations, routing platform 260 can update an estimated time of arrival. For example, routing platform 260 can determine, based on a first estimated time of arrival and an alteration to the input data from previously collected input data, a second estimated time of arrival that is different from the first estimated time of arrival. In this way, routing platform 260 dynamically determines an estimated time of arrival to enable enhanced vehicle tracking by a dispatcher, a customer, and/or the like.”).
Regarding claim 3, modified Shaukat teaches the limitations of claim 1. Shaukat further teaches wherein the one or more required events include one or more rest stops (see at least [0039]: “Driver device data collection module 282 includes one or more computing resources of cloud environment 250 implemented to obtain data from a driver device, such as a mobile device 205 assigned to a driver of a vehicle. In some implementations, driver device data collection module 282 can obtain data relating to a job status, such as a location of a driver, an estimated amount of time to complete a job based on a driver's assessment of the job, an update to the estimated amount of time to complete the job as the driver is completing the job, an indicator that a job is complete, an indicator that a driver is on a mandatory break (e.g., a break required by a contractual agreement, a legislative imperative, and/or the like), a non-mandatory break, and/or the like. In some implementations, driver device data collection module 282 can provide the data relating to the job status to data bus 288 and/or data repository 290.”).
Regarding claim 4, modified Shaukat teaches the limitations of claim 3. Shaukat further teaches wherein the one or more rest stops is required at a specified frequency, a specified duration, or a combination thereof; and wherein the one or more predicted events are based on the specified frequency, the specified duration, or a combination thereof (see at least [0039]: “In some implementations, driver device data collection module 282 can obtain data relating to a job status, such as a location of a driver, an estimated amount of time to complete a job based on a driver's assessment of the job, an update to the estimated amount of time to complete the job as the driver is completing the job, an indicator that a job is complete, an indicator that a driver is on a mandatory break (e.g., a break required by a contractual agreement, a legislative imperative, and/or the like), a non-mandatory break, and/or the like. In some implementations, driver device data collection module 282 can provide the data relating to the job status to data bus 288 and/or data repository 290.”; [0065]: “In some implementations, routing platform 260 may determine that the estimated time of arrival is different based on a heuristic. For example, routing platform 260 may determine that the estimated time of arrival is different based on determining that a mandatory type of driver break is to occur before the job rather than after the job, and the job will be delayed by a length of time corresponding to the mandatory type of driver break. In contrast, for a non-mandatory type of driver break, routing platform 260 may determine that an operator will reduce a length of time of the non-mandatory type of driver break to avoid being late to the job. Additionally, or alternatively, routing platform 260 may determine that the estimated time of arrival is different based on a predicted traffic condition, a predicted equipment availability, and/or the like associated with a state of the vehicle or a state of the operator.”).
Regarding claim 5, modified Shaukat teaches the limitations of claim 1. Shaukat further teaches wherein the updated ETA is iteratively updated as each of the one or more subsequent monitoring periods during the route is completed (see at least [0066]: “In some implementations, routing platform 260 can process the input data as a batch process. For example, periodically (e.g., once per hour, once per minute, etc.), routing platform 260 can process the input data to determine the route information for one or more jobs, one or more vehicles, and/or the like. Additionally, or alternatively, routing platform 260 can process the input data continuously as updated input data is received. For example, when a change to a predicted traffic pattern for a subsequent drive time is received, routing platform 260 can recalculate the estimated time of arrival based on the predicted traffic pattern.”).
Regarding claim 6, modified Shaukat teaches the limitations of claim 1. Shaukat further teaches wherein the ETA information is generated with respect to an expected route distance or time versus an actual route distance or time, one or more expected rest events versus one or more actual rest events, one or more expected task events versus one or more actual task events, an expected driving time versus an actual driving time, one or more expected traffic events versus one or more actual traffic events, or a combination thereof (see at least [0064]: “In this case, routing platform 260 can use the input data and the heuristic model to determine an estimated job duration, an estimated transportation duration, an estimated break duration, and/or the like, and can determine an estimated time of arrival at each job of a route for a driver. In some implementations, routing platform 260 can update an estimated time of arrival. For example, routing platform 260 can determine, based on a first estimated time of arrival and an alteration to the input data from previously collected input data, a second estimated time of arrival that is different from the first estimated time of arrival. In this way, routing platform 260 dynamically determines an estimated time of arrival to enable enhanced vehicle tracking by a dispatcher, a customer, and/or the like.”; [0070]: “In some implementations, routing platform 260 can identify a late job state. For example, based on the input data, routing platform 260 can determine that a job is late. Additionally, or alternatively, routing platform 260 can determine that a job is predicted to be late. For example, routing platform 260 can determine that, based on a predicted traffic condition based on historical traffic conditions, a predicted weather condition, a predicted job length, a location of a vehicle, and/or the like, a subsequent job is behind what is routed for (e.g., is predicted to start late, end late, and/or the like). In some implementations, routing platform 260 can determine that a vehicle is off path (e.g., is greater than a threshold distance from an expected path, a planned path, an indicated path, and/or the like).”).
Shaukat fails to explicitly teach utilizing a scorecard to report information data.
However, Cova teaches a method and system for generating supply chain management statistics from tracking data that utilizes a scorecard to report information data (see at least [0099]: “In some implementations, the user notification can be a report of the event notification, augmented by details extracted from the enterprise data, for example, if the event notification specifies that a security event has occurred, the system can generate a user notification that indicates that the items in the asset were in an asset for which a security event has occurred that an asset on its way to a particular supplier had a security event, that an asset being used to ship items from or to a particular division of the enterprise had a security event, or that an asset used to ship items associated with a particular product had a security event. In some implementations, the user notification also includes a dynamic estimated time of arrival for the asset, calculated, for example, from the data received about the asset's journey and historical lead time information gathered from past journeys along the same route.”; [0105]: “Examples of supply chain management statistics include, but are not limited to, estimated time of arrival for inventory, lead time, fulfillment risk, demand and supply balance, products inbound, perfect order fill rate, shipment fill rate, on-time shipment rate, on-time arrival rate, amount ordered, amount shipped, amount arrived, inventory in-transit, and carrier and vendor performance scorecards.”; [0113]: “The carrier scorecards indicate the performance of carriers over time. For example, the scorecard can calculate one or more of the statistics described above, such as lead time, for assets carried by a particular carrier and provide the statistics to the end user as an overview of the carrier's effectiveness. Similarly, vendor scorecards can be generated with vendor-specific statistics.”).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Shaukat to incorporate the teachings of Cova and provide a scorecard to report information data, with a reasonable expectation of success, in order provide an alternative means of reporting and presenting the information data.
Regarding claim 7, modified Shaukat teaches the limitations of claim 1. Shaukat further teaches wherein the initial set of assumptions or the one or more pre-trip predicted events relates to driver rest, use of a single driver, adherence to regulations, a full truckload shipment, no refueling break, an optimal route, no non-T&L trip related events, or a combination thereof (see at least [0013]: “In some implementations, routing platform 108 can determine an estimated time of arrival for the vehicle at one or more job sites for the driver of the vehicle. For example, based on information identifying a location of the vehicle, a status of the vehicle, a type of job that is to be completed by the driver of the vehicle (e.g., a length of the job), a schedule of availability of equipment that is to be obtained and used by the driver of the vehicle to complete a job, a current traffic condition, a predicted traffic condition, a current weather condition, a predicted weather condition, an availability of another driver and another vehicle to complete one or more jobs for the driver of the vehicle, and/or the like, routing platform 108 can determine the estimated time of arrival for at least one upcoming job.”).
Regarding claim 8, modified Shaukat teaches the limitations of claim 1. Shaukat further teaches after a completion of the T&L industry trip, presenting a user interface depicting a chronology of the one or more actual events determined from the real-time location trace data (see at least [0083]: “As further shown in FIG. 4, process 400 can include communicating with a device to transmit the alert or implement the response action (block 440). For example, routing platform 260 can transmit the alert to a mobile device 205, an external data source 270, and/or the like, and/or communicate with a mobile device 205, an external data source 270, and/or the like to implement the response action. In some implementations, routing platform 260 can communicate with a vehicle (e.g., a control device type of mobile device 205) to cause an autonomous vehicle to be dispatched, to change a path, to provide updated status information, and/or the like. In some implementations, routing platform 260 can cause the alert to be provided for display in a user interface of mobile device 205. For example, routing platform 260 can provide an alert identifying a change to an estimated time of arrival, and can cause the alert to be provided for display to notify a customer of the change to the estimated time of arrival. In some implementations, routing platform 260 can alter a route of jobs and provide information identifying the alteration to the route of jobs. In some implementations, routing platform 260 can cause a change to a path to be provided for display, can cause another vehicle to be dispatched, can automatically perform a customer relations task, can cause a calendar entry to be generated and/or updated in a calendar application of mobile device 205, and/or the like. In some implementations, based on tracking a location of a vehicle, routing platform 260 can provide information identifying a distance of a vehicle to a job site to a customer on the job site (e.g., to mobile device 205) to enable the customer to provide directions to the driver for a non-mapped path from a road to a location on the job site.”).
Regarding claim 9, modified Shaukat teaches the limitations of claim 1. Shaukat further teaches determining one or more factors contributing to an ETA deviation between the original ETA and the updated ETA based on the ETA information (see at least [0083]: “As further shown in FIG. 4, process 400 can include communicating with a device to transmit the alert or implement the response action (block 440). For example, routing platform 260 can transmit the alert to a mobile device 205, an external data source 270, and/or the like, and/or communicate with a mobile device 205, an external data source 270, and/or the like to implement the response action. In some implementations, routing platform 260 can communicate with a vehicle (e.g., a control device type of mobile device 205) to cause an autonomous vehicle to be dispatched, to change a path, to provide updated status information, and/or the like. In some implementations, routing platform 260 can cause the alert to be provided for display in a user interface of mobile device 205. For example, routing platform 260 can provide an alert identifying a change to an estimated time of arrival, and can cause the alert to be provided for display to notify a customer of the change to the estimated time of arrival. In some implementations, routing platform 260 can alter a route of jobs and provide information identifying the alteration to the route of jobs. In some implementations, routing platform 260 can cause a change to a path to be provided for display, can cause another vehicle to be dispatched, can automatically perform a customer relations task, can cause a calendar entry to be generated and/or updated in a calendar application of mobile device 205, and/or the like. In some implementations, based on tracking a location of a vehicle, routing platform 260 can provide information identifying a distance of a vehicle to a job site to a customer on the job site (e.g., to mobile device 205) to enable the customer to provide directions to the driver for a non-mapped path from a road to a location on the job site.”).
Shaukat fails to explicitly teach utilizing a scorecard to report information data.
However, Cova teaches a method and system for generating supply chain management statistics from tracking data that utilizes a scorecard to report information data (see at least [0099]: “In some implementations, the user notification can be a report of the event notification, augmented by details extracted from the enterprise data, for example, if the event notification specifies that a security event has occurred, the system can generate a user notification that indicates that the items in the asset were in an asset for which a security event has occurred that an asset on its way to a particular supplier had a security event, that an asset being used to ship items from or to a particular division of the enterprise had a security event, or that an asset used to ship items associated with a particular product had a security event. In some implementations, the user notification also includes a dynamic estimated time of arrival for the asset, calculated, for example, from the data received about the asset's journey and historical lead time information gathered from past journeys along the same route.”; [0105]: “Examples of supply chain management statistics include, but are not limited to, estimated time of arrival for inventory, lead time, fulfillment risk, demand and supply balance, products inbound, perfect order fill rate, shipment fill rate, on-time shipment rate, on-time arrival rate, amount ordered, amount shipped, amount arrived, inventory in-transit, and carrier and vendor performance scorecards.”; [0113]: “The carrier scorecards indicate the performance of carriers over time. For example, the scorecard can calculate one or more of the statistics described above, such as lead time, for assets carried by a particular carrier and provide the statistics to the end user as an overview of the carrier's effectiveness. Similarly, vendor scorecards can be generated with vendor-specific statistics.”).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Shaukat to incorporate the teachings of Cova and provide a scorecard to report information data, with a reasonable expectation of success, in order provide an alternative means of reporting and presenting the information data.
Regarding claim 10, modified Shaukat teaches the limitations of claim 1. Shaukat further teaches computing a compliance index based on an ETA deviation between the original ETA and the updated ETA, computing a regulatory deviation between the one or more required events and the one or more actual events, or a combination thereof (see at least [0014]: “As shown in FIG. 1B, and by reference number 120, routing platform 108 can provide output associated with the route information. As shown by reference number 122, routing platform 108 can provide output identifying an updated route to mobile device 106-1. For example, based on determining an updated estimated time of arrival based on the vehicle arriving at a job site late, a job taking less time than predicted, an item of equipment becoming available for the driver to borrow at an earlier time than expected, an accident causing a change to a traffic condition, a predicted rainstorm resulting in a predicted road closure, and/or the like, routing platform 108 can provide an updated route to the driver to identify an altered driving path for the driver, an altered estimated time of arrival for a job, an altered break schedule, an altered order of jobs, and/or the like. As shown by reference number 124, routing platform 108 can provide output identifying an updated estimated time of arrival to mobile device 106-2. For example, based on determining that the vehicle was 30 minutes late to a job site resulting in a shortened break during the job of 5 minutes less than routed for, and an altered traffic condition when the vehicle departs the job site 25 minutes after routed for, routing platform 108 can provide an estimated time of arrival of 45 minutes after routed for.”; [0040]: “Navigation device data collection module 284 includes one or more computing resources of cloud environment 250 implemented to obtain data from a navigation device, such as a mobile device 205 installed as a telematics device of a vehicle, a global positioning system (GPS) device of a vehicle, and/or the like. In some implementations, navigation device data collection module 284 can obtain data relating to a path (e.g., a set of directions being used by a driver to navigate to a job site), a deviation from a path (e.g., a change from an intended path to an actual path), an estimated time of arrival (e.g., calculated by the navigation device based on a path, a traffic condition, and/or the like), and/or the like.”).
Regarding claim 11, modified Shaukat teaches the limitations of claim 10. Shaukat further teaches transmitting an alert based on the ETA deviation, the regulatory deviation, or a combination thereof (see at least [0083]: “As further shown in FIG. 4, process 400 can include communicating with a device to transmit the alert or implement the response action (block 440). For example, routing platform 260 can transmit the alert to a mobile device 205, an external data source 270, and/or the like, and/or communicate with a mobile device 205, an external data source 270, and/or the like to implement the response action. In some implementations, routing platform 260 can communicate with a vehicle (e.g., a control device type of mobile device 205) to cause an autonomous vehicle to be dispatched, to change a path, to provide updated status information, and/or the like. In some implementations, routing platform 260 can cause the alert to be provided for display in a user interface of mobile device 205. For example, routing platform 260 can provide an alert identifying a change to an estimated time of arrival, and can cause the alert to be provided for display to notify a customer of the change to the estimated time of arrival. In some implementations, routing platform 260 can alter a route of jobs and provide information identifying the alteration to the route of jobs. In some implementations, routing platform 260 can cause a change to a path to be provided for display, can cause another vehicle to be dispatched, can automatically perform a customer relations task, can cause a calendar entry to be generated and/or updated in a calendar application of mobile device 205, and/or the like. In some implementations, based on tracking a location of a vehicle, routing platform 260 can provide information identifying a distance of a vehicle to a job site to a customer on the job site (e.g., to mobile device 205) to enable the customer to provide directions to the driver for a non-mapped path from a road to a location on the job site.”).
Regarding claim 12, modified Shaukat teaches the limitations of claim 1. Shaukat further teaches wherein the route is computed as a sequence of one or more driving events and one or more non-driving events (see at least [0014]: “As shown in FIG. 1B, and by reference number 120, routing platform 108 can provide output associated with the route information. As shown by reference number 122, routing platform 108 can provide output identifying an updated route to mobile device 106-1. For example, based on determining an updated estimated time of arrival based on the vehicle arriving at a job site late, a job taking less time than predicted, an item of equipment becoming available for the driver to borrow at an earlier time than expected, an accident causing a change to a traffic condition, a predicted rainstorm resulting in a predicted road closure, and/or the like, routing platform 108 can provide an updated route to the driver to identify an altered driving path for the driver, an altered estimated time of arrival for a job, an altered break schedule, an altered order of jobs, and/or the like. As shown by reference number 124, routing platform 108 can provide output identifying an updated estimated time of arrival to mobile device 106-2. For example, based on determining that the vehicle was 30 minutes late to a job site resulting in a shortened break during the job of 5 minutes less than routed for, and an altered traffic condition when the vehicle departs the job site 25 minutes after routed for, routing platform 108 can provide an estimated time of arrival of 45 minutes after routed for.”).
Regarding claim 13, Shaukat teaches an apparatus (see at least abstract: “The device can determine, based on the state of the first job, a plurality of estimated times of arrival of the vehicle at two or more downstream jobs, of the plurality of jobs, occurring after the first job. The device can determine, based on the plurality of estimated times of arrival, a set of alerts or a set of response actions relating to the plurality of estimated times of arrival of the vehicle. The device can communicate with at least one customer device to provide the alert or implement the response action.”) comprising:
at least one processor (see at least Fig. 3 and [0047]: “As shown in FIG. 3, device 300 can include a bus 310, a processor 320, a memory 330, a storage component 340, an input component 350, an output component 360, and a communication interface 370.”); and
at least one memory including computer program code for one or more programs, the at least one memory and the computer program code configured to, with the at least one processor (see at least [0052]: “Device 300 can perform one or more processes described herein. Device 300 can perform these processes based on processor 320 executing software instructions stored by a non-transitory computer-readable medium, such as memory 330 and/or storage component 340. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.”), cause the apparatus to perform at least the following:
computing an original estimated time of arrival (ETA) for a vehicle traveling on a route for a trip, wherein the trip is subject to one or more required events during the route, and wherein the original ETA is computed based on an initial set of assumptions relating to one or more pre-trip predicted events and the one or more required events (see at least [0013]: “In some implementations, routing platform 108 can determine an estimated time of arrival for the vehicle at one or more job sites for the driver of the vehicle. For example, based on information identifying a location of the vehicle, a status of the vehicle, a type of job that is to be completed by the driver of the vehicle (e.g., a length of the job), a schedule of availability of equipment that is to be obtained and used by the driver of the vehicle to complete a job, a current traffic condition, a predicted traffic condition, a current weather condition, a predicted weather condition, an availability of another driver and another vehicle to complete one or more jobs for the driver of the vehicle, and/or the like, routing platform 108 can determine the estimated time of arrival for at least one upcoming job.”);
monitoring real-time location trace data collected from one or more sensors of the vehicle on the route during a monitoring period (see at least [0013]: “In some implementations, routing platform 108 can use a heuristic, conditional logic, a machine learning technique, a deep learning technique, a neural network technique, and/or the like to dynamically update the estimated time of arrival and/or automatically track a status of the vehicle and the driver. For example, routing platform 108 can use a heuristic to process input data and determine whether the driver has arrived at a job site.”; [0037]: “External data source 270 includes one or more devices associated with receiving, generating, storing, processing, and/or providing information associated with determining an estimated time of arrival. For example, external data source 270 can include a server identifying a route for a set of vehicles, a schedule for availability of an item (e.g., equipment that is to be used to complete an installation, a service, a repair, and/or the like), a traffic condition, a weather condition, and/or the like. In some implementations, external data source 270 can include one or more sensors, such as one or more traffic sensors, weather sensors, location sensors, and/or the like. In some aspects, external data sources 270 can provide data in real-time or near real-time (e.g., within a threshold period of time of data collection, data acquisition, and/or the like).”; [0040]: “Navigation device data collection module 284 includes one or more computing resources of cloud environment 250 implemented to obtain data from a navigation device, such as a mobile device 205 installed as a telematics device of a vehicle, a global positioning system (GPS) device of a vehicle, and/or the like. In some implementations, navigation device data collection module 284 can obtain data relating to a path (e.g., a set of directions being used by a driver to navigate to a job site), a deviation from a path (e.g., a change from an intended path to an actual path), an estimated time of arrival (e.g., calculated by the navigation device based on a path, a traffic condition, and/or the like), and/or the like. In some implementations, navigation device data collection module 284 can provide the data to data bus 288. For example, navigation device data collection module 284 can provide an update identifying a path of a vehicle.”);
processing the real-time location trace data to determine one or more actual events of the vehicle, the driver, or a combination occurring during the monitoring period (see at least [0012]: “Additionally, or alternatively, routing platform 108 can receive vehicle data from telematics device 104, such as data identifying a location of the vehicle, a speed of the vehicle, a status of the vehicle (e.g., an engine status, vehicle location, vehicle alerts, vehicle sensor readings, vehicle speed, vehicle direction, vehicle geofence proximity, and/or status information from one or more other vehicle sensors of the vehicle), and/or the like.”; [0013]: “In some implementations, routing platform 108 can determine an estimated time of arrival for the vehicle at one or more job sites for the driver of the vehicle. For example, based on information identifying a location of the vehicle, a status of the vehicle, a type of job that is to be completed by the driver of the vehicle (e.g., a length of the job), a schedule of availability of equipment that is to be obtained and used by the driver of the vehicle to complete a job, a current traffic condition, a predicted traffic condition, a current weather condition, a predicted weather condition, an availability of another driver and another vehicle to complete one or more jobs for the driver of the vehicle, and/or the like, routing platform 108 can determine the estimated time of arrival for at least one upcoming job.”);
generating a real-time ETA information that compares the one or more actual events to the one or more required events, the one or more pre-trip predicted events, one or more prior events determined for one or more previous monitoring periods, or a combination thereof (see at least [0038]: “As shown in FIG. 2B, routing platform 260 can include a driver device data collection module 282, a navigation device data collection module 284, one or more other data collection modules 286, a data bus 288, a data repository module 290, an estimated time of arrival (ETA) service module 292, and a data output module 294.”; [0068]: “Similarly, routing platform 260 can automatically determine whether a break will be shortened (e.g., which may relate to a state of an operator, such as a driver) using conditional logic, such as based on whether the break is a mandatory break (e.g., a legally obligated or contractually obligated break), which will not be shortened, or a non-mandatory break, which can be shortened, thereby improving an accuracy of an estimated time of arrival determination relative to another technique that does not distinguish between types of breaks and/or does not account for changes to non-mandatory breaks to ensure timeliness.”);
processing the real-time ETA using machine learning to learn relationships between features obtained from a database and the real-time ETA (see at least Fig. 1A and [0013]: “For example, based on information identifying a location of the vehicle, a status of the vehicle, a type of job that is to be completed by the driver of the vehicle (e.g., a length of the job), a schedule of availability of equipment that is to be obtained and used by the driver of the vehicle to complete a job, a current traffic condition, a predicted traffic condition, a current weather condition, a predicted weather condition, an availability of another driver and another vehicle to complete one or more jobs for the driver of the vehicle, and/or the like, routing platform 108 can determine the estimated time of arrival for at least one upcoming job. In some implementations, routing platform 108 can use a heuristic, conditional logic, a machine learning technique, a deep learning technique, a neural network technique, and/or the like to dynamically update the estimated time of arrival and/or automatically track a status of the vehicle and the driver.”);
determining one or more predicted events for one or more subsequent monitoring periods based on the learned relationships of the machine learning (see at least [0013]: “In some implementations, routing platform 108 can use a heuristic, conditional logic, a machine learning technique, a deep learning technique, a neural network technique, and/or the like to dynamically update the estimated time of arrival and/or automatically track a status of the vehicle and the driver.”; [0068]: “Similarly, routing platform 260 can automatically determine whether a break will be shortened (e.g., which may relate to a state of an operator, such as a driver) using conditional logic, such as based on whether the break is a mandatory break (e.g., a legally obligated or contractually obligated break), which will not be shortened, or a non-mandatory break, which can be shortened, thereby improving an accuracy of an estimated time of arrival determination relative to another technique that does not distinguish between types of breaks and/or does not account for changes to non-mandatory breaks to ensure timeliness.”);
determining an updated ETA for the route based on the one or more predicted events (see at least [0013]: “In some implementations, routing platform 108 can use a heuristic, conditional logic, a machine learning technique, a deep learning technique, a neural network technique, and/or the like to dynamically update the estimated time of arrival and/or automatically track a status of the vehicle and the driver.”; [0064]: “In some implementations, routing platform 260 can update an estimated time of arrival. For example, routing platform 260 can determine, based on a first estimated time of arrival and an alteration to the input data from previously collected input data, a second estimated time of arrival that is different from the first estimated time of arrival. In this way, routing platform 260 dynamically determines an estimated time of arrival to enable enhanced vehicle tracking by a dispatcher, a customer, and/or the like.”; [0068]: “Similarly, routing platform 260 can automatically determine whether a break will be shortened (e.g., which may relate to a state of an operator, such as a driver) using conditional logic, such as based on whether the break is a mandatory break (e.g., a legally obligated or contractually obligated break), which will not be shortened, or a non-mandatory break, which can be shortened, thereby improving an accuracy of an estimated time of arrival determination relative to another technique that does not distinguish between types of breaks and/or does not account for changes to non-mandatory breaks to ensure timeliness.”); and
providing the updated ETA, the real-time ETA information, or a combination thereof as an output (see at least [0014]: “As shown in FIG. 1B, and by reference number 120, routing platform 108 can provide output associated with the route information. As shown by reference number 122, routing platform 108 can provide output identifying an updated route to mobile device 106-1. For example, based on determining an updated estimated time of arrival based on the vehicle arriving at a job site late, a job taking less time than predicted, an item of equipment becoming available for the driver to borrow at an earlier time than expected, an accident causing a change to a traffic condition, a predicted rainstorm resulting in a predicted road closure, and/or the like, routing platform 108 can provide an updated route to the driver to identify an altered driving path for the driver, an altered estimated time of arrival for a job, an altered break schedule, an altered order of jobs, and/or the like. As shown by reference number 124, routing platform 108 can provide output identifying an updated estimated time of arrival to mobile device 106-2. For example, based on determining that the vehicle was 30 minutes late to a job site resulting in a shortened break during the job of 5 minutes less than routed for, and an altered traffic condition when the vehicle departs the job site 25 minutes after routed for, routing platform 108 can provide an estimated time of arrival of 45 minutes after routed for.”).
Shaukat fails to explicitly teach using a machine learning model to learn relationships between map features obtained from a geographic database and deviations in the real-time ETA.
However, Cirit teaches a method and system for predicting an estimated time of arrival of a vehicle that uses a machine learning model to learn relationships between map features obtained from a geographic database and deviations in a real-time ETA (see at least Figs. 1-3 and [0028]: “The machine-learned model 160 (e.g., ETA post-processing model) according to the present disclosure implements a hybrid approach that treats the routing engine 150 ETA as a noisy estimate of the true arrival time. In some embodiments, the machine-learned model 160 may be a deep learning-based model to predict the difference between the routing engine 150 ETA and the observed arrival time. As shown in FIG. 1, the routing APIs 170 may receive an ETA request from an ETA consumer on the ETA consumer system 125. For example, the request may be based on a user request for a vehicle to conduct a trip that includes a first location (e.g., end location of a trip). The routing APIs 170 may also receive corresponding feature data for the trip from the ETA consumer system 125. Based on the request, the routing engine 150 with access to map data 140 and real-time traffic data 145 may compute the predicted ETA for the vehicle to travel from a particular location (e.g., current location or begin location) to the first location.”: [0037]: “The features may be categorized into different categories. For example, the features may be categorized into continuous features 311, categorical features 312, geospatial features 313, calibration features 314, and other features 315.”).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Shaukat to incorporate the teachings of Cirit and provide means to use a machine learning model to learn relationships between map features obtained from a geographic database and deviations in a real-time ETA, with a reasonable expectation of success, in order a refined the ETA using a machine-learned model that takes a plurality of features as input associated with a trip [0004].
The combination of Shaukat and Cirit fails to explicitly teach utilizing a scorecard to report information data.
However, Cova teaches a method and system for generating supply chain management statistics from tracking data that utilizes a scorecard to report information data (see at least [0099]: “In some implementations, the user notification can be a report of the event notification, augmented by details extracted from the enterprise data, for example, if the event notification specifies that a security event has occurred, the system can generate a user notification that indicates that the items in the asset were in an asset for which a security event has occurred that an asset on its way to a particular supplier had a security event, that an asset being used to ship items from or to a particular division of the enterprise had a security event, or that an asset used to ship items associated with a particular product had a security event. In some implementations, the user notification also includes a dynamic estimated time of arrival for the asset, calculated, for example, from the data received about the asset's journey and historical lead time information gathered from past journeys along the same route.”; [0105]: “Examples of supply chain management statistics include, but are not limited to, estimated time of arrival for inventory, lead time, fulfillment risk, demand and supply balance, products inbound, perfect order fill rate, shipment fill rate, on-time shipment rate, on-time arrival rate, amount ordered, amount shipped, amount arrived, inventory in-transit, and carrier and vendor performance scorecards.”; [0113]: “The carrier scorecards indicate the performance of carriers over time. For example, the scorecard can calculate one or more of the statistics described above, such as lead time, for assets carried by a particular carrier and provide the statistics to the end user as an overview of the carrier's effectiveness. Similarly, vendor scorecards can be generated with vendor-specific statistics.”).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Shaukat and Cirit to incorporate the teachings of Cova and provide a scorecard to report information data, with a reasonable expectation of success, in order provide an alternative means of reporting and presenting the information data.
Regarding claim 14, modified Shaukat teaches the limitations of claim 13. Shaukat further teaches wherein the initial set of assumptions is based, at least in part, on prior location trace data for one or more previous trips made by the driver (see at least [0064]: “In some implementations, routing platform 260 can update an estimated time of arrival. For example, routing platform 260 can determine, based on a first estimated time of arrival and an alteration to the input data from previously collected input data, a second estimated time of arrival that is different from the first estimated time of arrival. In this way, routing platform 260 dynamically determines an estimated time of arrival to enable enhanced vehicle tracking by a dispatcher, a customer, and/or the like.”).
Regarding claim 15, modified Shaukat teaches the limitations of claim 13. Shaukat further teaches wherein the one or more required events include one or more rest stops (see at least [0039]: “Driver device data collection module 282 includes one or more computing resources of cloud environment 250 implemented to obtain data from a driver device, such as a mobile device 205 assigned to a driver of a vehicle. In some implementations, driver device data collection module 282 can obtain data relating to a job status, such as a location of a driver, an estimated amount of time to complete a job based on a driver's assessment of the job, an update to the estimated amount of time to complete the job as the driver is completing the job, an indicator that a job is complete, an indicator that a driver is on a mandatory break (e.g., a break required by a contractual agreement, a legislative imperative, and/or the like), a non-mandatory break, and/or the like. In some implementations, driver device data collection module 282 can provide the data relating to the job status to data bus 288 and/or data repository 290.”).
Regarding claim 16, modified Shaukat teaches the limitations of claim 15. Shaukat further teaches wherein the one or more rest stops is required at a specified frequency, a specified duration, or a combination thereof; and wherein the one or more predicted events are based on the specified frequency, the specified duration, or a combination thereof (see at least [0039]: “In some implementations, driver device data collection module 282 can obtain data relating to a job status, such as a location of a driver, an estimated amount of time to complete a job based on a driver's assessment of the job, an update to the estimated amount of time to complete the job as the driver is completing the job, an indicator that a job is complete, an indicator that a driver is on a mandatory break (e.g., a break required by a contractual agreement, a legislative imperative, and/or the like), a non-mandatory break, and/or the like. In some implementations, driver device data collection module 282 can provide the data relating to the job status to data bus 288 and/or data repository 290.”; [0065]: “In some implementations, routing platform 260 may determine that the estimated time of arrival is different based on a heuristic. For example, routing platform 260 may determine that the estimated time of arrival is different based on determining that a mandatory type of driver break is to occur before the job rather than after the job, and the job will be delayed by a length of time corresponding to the mandatory type of driver break. In contrast, for a non-mandatory type of driver break, routing platform 260 may determine that an operator will reduce a length of time of the non-mandatory type of driver break to avoid being late to the job. Additionally, or alternatively, routing platform 260 may determine that the estimated time of arrival is different based on a predicted traffic condition, a predicted equipment availability, and/or the like associated with a state of the vehicle or a state of the operator.”).
Regarding claim 17, Shaukat teaches a non-transitory computer-readable storage medium carrying one or more sequences of one or more instructions which, when executed by one or more processors (see at least [0052]: “Device 300 can perform one or more processes described herein. Device 300 can perform these processes based on processor 320 executing software instructions stored by a non-transitory computer-readable medium, such as memory 330 and/or storage component 340. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.”), cause an apparatus to at least perform the following steps:
computing an original estimated time of arrival (ETA) for a vehicle traveling on a route for trip, wherein the trip is subject to one or more required events during the route, and wherein the original ETA is computed based on an initial set of assumptions relating to one or more pre-trip predicted events and the one or more required events (see at least [0013]: “In some implementations, routing platform 108 can determine an estimated time of arrival for the vehicle at one or more job sites for the driver of the vehicle. For example, based on information identifying a location of the vehicle, a status of the vehicle, a type of job that is to be completed by the driver of the vehicle (e.g., a length of the job), a schedule of availability of equipment that is to be obtained and used by the driver of the vehicle to complete a job, a current traffic condition, a predicted traffic condition, a current weather condition, a predicted weather condition, an availability of another driver and another vehicle to complete one or more jobs for the driver of the vehicle, and/or the like, routing platform 108 can determine the estimated time of arrival for at least one upcoming job.”);
monitoring real-time location trace data collected from one or more sensors of the vehicle on the route during a monitoring period (see at least [0013]: “In some implementations, routing platform 108 can use a heuristic, conditional logic, a machine learning technique, a deep learning technique, a neural network technique, and/or the like to dynamically update the estimated time of arrival and/or automatically track a status of the vehicle and the driver. For example, routing platform 108 can use a heuristic to process input data and determine whether the driver has arrived at a job site.”; [0037]: “External data source 270 includes one or more devices associated with receiving, generating, storing, processing, and/or providing information associated with determining an estimated time of arrival. For example, external data source 270 can include a server identifying a route for a set of vehicles, a schedule for availability of an item (e.g., equipment that is to be used to complete an installation, a service, a repair, and/or the like), a traffic condition, a weather condition, and/or the like. In some implementations, external data source 270 can include one or more sensors, such as one or more traffic sensors, weather sensors, location sensors, and/or the like. In some aspects, external data sources 270 can provide data in real-time or near real-time (e.g., within a threshold period of time of data collection, data acquisition, and/or the like).”; [0040]: “Navigation device data collection module 284 includes one or more computing resources of cloud environment 250 implemented to obtain data from a navigation device, such as a mobile device 205 installed as a telematics device of a vehicle, a global positioning system (GPS) device of a vehicle, and/or the like. In some implementations, navigation device data collection module 284 can obtain data relating to a path (e.g., a set of directions being used by a driver to navigate to a job site), a deviation from a path (e.g., a change from an intended path to an actual path), an estimated time of arrival (e.g., calculated by the navigation device based on a path, a traffic condition, and/or the like), and/or the like. In some implementations, navigation device data collection module 284 can provide the data to data bus 288. For example, navigation device data collection module 284 can provide an update identifying a path of a vehicle.”);
processing the real-time location trace data to determine one or more actual events of the vehicle, the driver, or a combination occurring during the monitoring period (see at least [0012]: “Additionally, or alternatively, routing platform 108 can receive vehicle data from telematics device 104, such as data identifying a location of the vehicle, a speed of the vehicle, a status of the vehicle (e.g., an engine status, vehicle location, vehicle alerts, vehicle sensor readings, vehicle speed, vehicle direction, vehicle geofence proximity, and/or status information from one or more other vehicle sensors of the vehicle), and/or the like.”; [0013]: “In some implementations, routing platform 108 can determine an estimated time of arrival for the vehicle at one or more job sites for the driver of the vehicle. For example, based on information identifying a location of the vehicle, a status of the vehicle, a type of job that is to be completed by the driver of the vehicle (e.g., a length of the job), a schedule of availability of equipment that is to be obtained and used by the driver of the vehicle to complete a job, a current traffic condition, a predicted traffic condition, a current weather condition, a predicted weather condition, an availability of another driver and another vehicle to complete one or more jobs for the driver of the vehicle, and/or the like, routing platform 108 can determine the estimated time of arrival for at least one upcoming job.”);
generating a real-time ETA information that compares the one or more actual events to the one or more required events, the one or more pre-trip predicted events, one or more prior events determined for one or more previous monitoring periods, or a combination thereof (see at least [0038]: “As shown in FIG. 2B, routing platform 260 can include a driver device data collection module 282, a navigation device data collection module 284, one or more other data collection modules 286, a data bus 288, a data repository module 290, an estimated time of arrival (ETA) service module 292, and a data output module 294.”; [0068]: “Similarly, routing platform 260 can automatically determine whether a break will be shortened (e.g., which may relate to a state of an operator, such as a driver) using conditional logic, such as based on whether the break is a mandatory break (e.g., a legally obligated or contractually obligated break), which will not be shortened, or a non-mandatory break, which can be shortened, thereby improving an accuracy of an estimated time of arrival determination relative to another technique that does not distinguish between types of breaks and/or does not account for changes to non-mandatory breaks to ensure timeliness.”);
analyzing the real-time ETA using machine learning to learn relationships between features obtained from a database and the real-time ETA (see at least Fig. 1A and [0013]: “For example, based on information identifying a location of the vehicle, a status of the vehicle, a type of job that is to be completed by the driver of the vehicle (e.g., a length of the job), a schedule of availability of equipment that is to be obtained and used by the driver of the vehicle to complete a job, a current traffic condition, a predicted traffic condition, a current weather condition, a predicted weather condition, an availability of another driver and another vehicle to complete one or more jobs for the driver of the vehicle, and/or the like, routing platform 108 can determine the estimated time of arrival for at least one upcoming job. In some implementations, routing platform 108 can use a heuristic, conditional logic, a machine learning technique, a deep learning technique, a neural network technique, and/or the like to dynamically update the estimated time of arrival and/or automatically track a status of the vehicle and the driver.”);
determining one or more predicted events for one or more subsequent monitoring periods based on learned relationships of the machine learning (see at least [0013]: “In some implementations, routing platform 108 can use a heuristic, conditional logic, a machine learning technique, a deep learning technique, a neural network technique, and/or the like to dynamically update the estimated time of arrival and/or automatically track a status of the vehicle and the driver.”; [0068]: “Similarly, routing platform 260 can automatically determine whether a break will be shortened (e.g., which may relate to a state of an operator, such as a driver) using conditional logic, such as based on whether the break is a mandatory break (e.g., a legally obligated or contractually obligated break), which will not be shortened, or a non-mandatory break, which can be shortened, thereby improving an accuracy of an estimated time of arrival determination relative to another technique that does not distinguish between types of breaks and/or does not account for changes to non-mandatory breaks to ensure timeliness.”);
determining an updated ETA for the route based on the one or more predicted events (see at least [0013]: “In some implementations, routing platform 108 can use a heuristic, conditional logic, a machine learning technique, a deep learning technique, a neural network technique, and/or the like to dynamically update the estimated time of arrival and/or automatically track a status of the vehicle and the driver.”; [0064]: “In some implementations, routing platform 260 can update an estimated time of arrival. For example, routing platform 260 can determine, based on a first estimated time of arrival and an alteration to the input data from previously collected input data, a second estimated time of arrival that is different from the first estimated time of arrival. In this way, routing platform 260 dynamically determines an estimated time of arrival to enable enhanced vehicle tracking by a dispatcher, a customer, and/or the like.”; [0068]: “Similarly, routing platform 260 can automatically determine whether a break will be shortened (e.g., which may relate to a state of an operator, such as a driver) using conditional logic, such as based on whether the break is a mandatory break (e.g., a legally obligated or contractually obligated break), which will not be shortened, or a non-mandatory break, which can be shortened, thereby improving an accuracy of an estimated time of arrival determination relative to another technique that does not distinguish between types of breaks and/or does not account for changes to non-mandatory breaks to ensure timeliness.”); and
providing the updated ETA, the real-time ETA information, or a combination thereof as an output (see at least [0014]: “As shown in FIG. 1B, and by reference number 120, routing platform 108 can provide output associated with the route information. As shown by reference number 122, routing platform 108 can provide output identifying an updated route to mobile device 106-1. For example, based on determining an updated estimated time of arrival based on the vehicle arriving at a job site late, a job taking less time than predicted, an item of equipment becoming available for the driver to borrow at an earlier time than expected, an accident causing a change to a traffic condition, a predicted rainstorm resulting in a predicted road closure, and/or the like, routing platform 108 can provide an updated route to the driver to identify an altered driving path for the driver, an altered estimated time of arrival for a job, an altered break schedule, an altered order of jobs, and/or the like. As shown by reference number 124, routing platform 108 can provide output identifying an updated estimated time of arrival to mobile device 106-2. For example, based on determining that the vehicle was 30 minutes late to a job site resulting in a shortened break during the job of 5 minutes less than routed for, and an altered traffic condition when the vehicle departs the job site 25 minutes after routed for, routing platform 108 can provide an estimated time of arrival of 45 minutes after routed for.”).
Shaukat fails to explicitly teach using a machine learning model to learn relationships between map features obtained from a geographic database and deviations in the real-time ETA.
However, Cirit teaches a method and system for predicting an estimated time of arrival of a vehicle that uses a machine learning model to learn relationships between map features obtained from a geographic database and deviations in a real-time ETA (see at least Figs. 1-3 and [0028]: “The machine-learned model 160 (e.g., ETA post-processing model) according to the present disclosure implements a hybrid approach that treats the routing engine 150 ETA as a noisy estimate of the true arrival time. In some embodiments, the machine-learned model 160 may be a deep learning-based model to predict the difference between the routing engine 150 ETA and the observed arrival time. As shown in FIG. 1, the routing APIs 170 may receive an ETA request from an ETA consumer on the ETA consumer system 125. For example, the request may be based on a user request for a vehicle to conduct a trip that includes a first location (e.g., end location of a trip). The routing APIs 170 may also receive corresponding feature data for the trip from the ETA consumer system 125. Based on the request, the routing engine 150 with access to map data 140 and real-time traffic data 145 may compute the predicted ETA for the vehicle to travel from a particular location (e.g., current location or begin location) to the first location.”: [0037]: “The features may be categorized into different categories. For example, the features may be categorized into continuous features 311, categorical features 312, geospatial features 313, calibration features 314, and other features 315.”).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Shaukat to incorporate the teachings of Cirit and provide means to use a machine learning model to learn relationships between map features obtained from a geographic database and deviations in a real-time ETA, with a reasonable expectation of success, in order a refined the ETA using a machine-learned model that takes a plurality of features as input associated with a trip [0004].
Shaukat fails to explicitly teach utilizing a scorecard to report information data.
However, Cova teaches a method and system for generating supply chain management statistics from tracking data that utilizes a scorecard to report information data (see at least [0099]: “In some implementations, the user notification can be a report of the event notification, augmented by details extracted from the enterprise data, for example, if the event notification specifies that a security event has occurred, the system can generate a user notification that indicates that the items in the asset were in an asset for which a security event has occurred that an asset on its way to a particular supplier had a security event, that an asset being used to ship items from or to a particular division of the enterprise had a security event, or that an asset used to ship items associated with a particular product had a security event. In some implementations, the user notification also includes a dynamic estimated time of arrival for the asset, calculated, for example, from the data received about the asset's journey and historical lead time information gathered from past journeys along the same route.”; [0105]: “Examples of supply chain management statistics include, but are not limited to, estimated time of arrival for inventory, lead time, fulfillment risk, demand and supply balance, products inbound, perfect order fill rate, shipment fill rate, on-time shipment rate, on-time arrival rate, amount ordered, amount shipped, amount arrived, inventory in-transit, and carrier and vendor performance scorecards.”; [0113]: “The carrier scorecards indicate the performance of carriers over time. For example, the scorecard can calculate one or more of the statistics described above, such as lead time, for assets carried by a particular carrier and provide the statistics to the end user as an overview of the carrier's effectiveness. Similarly, vendor scorecards can be generated with vendor-specific statistics.”).
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Shaukat to incorporate the teachings of Cova and provide a scorecard to report information data, with a reasonable expectation of success, in order provide an alternative means of reporting and presenting the information data.
Regarding claim 18, modified Shaukat teaches the limitations of claim 17. Shaukat further teaches wherein the initial set of assumptions is based, at least in part, on prior location trace data for one or more previous trips made by the driver (see at least [0064]: “In some implementations, routing platform 260 can update an estimated time of arrival. For example, routing platform 260 can determine, based on a first estimated time of arrival and an alteration to the input data from previously collected input data, a second estimated time of arrival that is different from the first estimated time of arrival. In this way, routing platform 260 dynamically determines an estimated time of arrival to enable enhanced vehicle tracking by a dispatcher, a customer, and/or the like.”).
Regarding claim 19, modified Shaukat teaches the limitations of claim 17. Shaukat further teaches wherein the one or more required events include one or more rest stops (see at least [0039]: “Driver device data collection module 282 includes one or more computing resources of cloud environment 250 implemented to obtain data from a driver device, such as a mobile device 205 assigned to a driver of a vehicle. In some implementations, driver device data collection module 282 can obtain data relating to a job status, such as a location of a driver, an estimated amount of time to complete a job based on a driver's assessment of the job, an update to the estimated amount of time to complete the job as the driver is completing the job, an indicator that a job is complete, an indicator that a driver is on a mandatory break (e.g., a break required by a contractual agreement, a legislative imperative, and/or the like), a non-mandatory break, and/or the like. In some implementations, driver device data collection module 282 can provide the data relating to the job status to data bus 288 and/or data repository 290.”).
Regarding claim 20, modified Shaukat teaches the limitations of claim 19. Shaukat further teaches wherein the one or more rest stops is required at a specified frequency, a specified duration, or a combination thereof; and wherein the one or more predicted events are based on the specified frequency, the specified duration, or a combination thereof (see at least [0039]: “In some implementations, driver device data collection module 282 can obtain data relating to a job status, such as a location of a driver, an estimated amount of time to complete a job based on a driver's assessment of the job, an update to the estimated amount of time to complete the job as the driver is completing the job, an indicator that a job is complete, an indicator that a driver is on a mandatory break (e.g., a break required by a contractual agreement, a legislative imperative, and/or the like), a non-mandatory break, and/or the like. In some implementations, driver device data collection module 282 can provide the data relating to the job status to data bus 288 and/or data repository 290.”; [0065]: “In some implementations, routing platform 260 may determine that the estimated time of arrival is different based on a heuristic. For example, routing platform 260 may determine that the estimated time of arrival is different based on determining that a mandatory type of driver break is to occur before the job rather than after the job, and the job will be delayed by a length of time corresponding to the mandatory type of driver break. In contrast, for a non-mandatory type of driver break, routing platform 260 may determine that an operator will reduce a length of time of the non-mandatory type of driver break to avoid being late to the job. Additionally, or alternatively, routing platform 260 may determine that the estimated time of arrival is different based on a predicted traffic condition, a predicted equipment availability, and/or the like associated with a state of the vehicle or a state of the operator.”).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TIEN MINH LE whose telephone number is (571)272-3903. The examiner can normally be reached Monday to Friday (8:30am-5:30pm eastern time).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Khoi Tran can be reached on (571)272-6919. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/T.M.L./
Examiner, Art Unit 3656
/KHOI H TRAN/Supervisory Patent Examiner, Art Unit 3656