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 .
Status of the Application
The following is a Final Office Action in response to claims filed 05/26/2026.
Claims 1-20 are pending.
Claims 1-20 have been examined.
The amendments and remarks regarding 35 USC 101 and submitted on 05/26/2026 are found persuasive, the previously presented 35 USC 101 rejection is withdrawn.
Terminal Disclaimer
The terminal disclaimer submitted on 05/26/2026 is acknowledged.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-9, 11-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Luckay (US Patent Publication 2020/0286021) in view of Newell (US Patent Publication 2022/0092530).
Regarding claims 1, 12 and 20, Luckay discloses a system, comprising:
a server computer comprising one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the one or more processors (Fig. 2 and [0167] As will be understood by those of skill in the art, in some embodiments, the processes set forth in the following material may be performed on a computer network. The computer network having a central server, the central server having a processor, data storage, such as databases and memories, and communications features to allow wired or wireless communication with various parts of the networks, including terminals and any other desired network access point or means.);
a method (abstract);
and a non-transitory computer readable medium storing instructions that, when executed on a server computer (Fig. 2 and [0167] As will be understood by those of skill in the art, in some embodiments, the processes set forth in the following material may be performed on a computer network. The computer network having a central server, the central server having a processor, data storage, such as databases and memories, and communications features to allow wired or wireless communication with various parts of the networks, including terminals and any other desired network access point or means.), cause the server computer to perform steps comprising:
monitor a plurality of vehicles operated by a plurality of drivers performing a plurality of routes according to a corresponding plurality of route schedules to service a plurality of ride service requests, comprising ([0052] The vehicle route control component 230 may store, monitor, and update a designated route of the vehicles 110a-b based on the pickup and delivery locations(s) of the user request. For example, each of the vehicles 110a-b may travel within the geographic region 105 according to a route that is stored in and monitored by the vehicle route control component 230. In some embodiments, the vehicle route control component 230 may work in conjunction with the vehicle location management component 220 to monitor the routes for the vehicles 110a-b. In some embodiments, if the vehicle route control component 230 determines that a vehicle 110 is off its route by a threshold amount, the vehicle route control component 230 may generate an alarm or an alert. [0053] In some embodiments, the vehicle route control component 230 may monitor routes for all first-party vehicles 110a and all third-party vehicles 110b that are transporting items according to user requests.);
receiving real-time global position system (“GPS”) information for the plurality of vehicles ([0099] FIG. 8 is a block diagram of an exemplary delivery vehicle. The delivery vehicle 110 shown in FIG. 8 may be an exemplary embodiment of the delivery vehicles 110a-b shown in FIG. 1. The exemplary delivery vehicle 110 includes a global positioning system (GPS) receiver 805, vehicle navigation component 810, vehicle route database 812, a vehicle control component 815, and a radio link 820. The radio link 820 may enable one or more of the GPS receiver 805, vehicle navigation component 810, or vehicle control component 815 to communicate wirelessly with other components of the disclosed methods and systems, such as any of the components shown in FIG. 2.), and
tracking the plurality of vehicles via one or more devices comprising a driver device, a provider device, a dispatch control center device, a vehicle device, or a ride requester device to determine that a vehicle has made an exception ([0099] FIG. 8 is a block diagram of an exemplary delivery vehicle. The delivery vehicle 110 shown in FIG. 8 may be an exemplary embodiment of the delivery vehicles 110a-b shown in FIG. 1. The exemplary delivery vehicle 110 includes a global positioning system (GPS) receiver 805, vehicle navigation component 810, vehicle route database 812, a vehicle control component 815, and a radio link 820. The radio link 820 may enable one or more of the GPS receiver 805, vehicle navigation component 810, or vehicle control component 815 to communicate wirelessly with other components of the disclosed methods and systems, such as any of the components shown in FIG. 2. [0143] In some embodiments, the confirmation may include tracking information with which the user may track the status of the vehicle and/or the item being transported. For example, the user may use the tracking information to determine when the vehicle will arrive at the pickup location and where the vehicle is along its delivery route. [0144] At block 1255, the delivery system 100 may provide tracking information to the user for use in tracking the item. The tracking information may be provided via the app or via one or more electronic communication methods. In some embodiments, the tracking information may include relative locations of the vehicle while the vehicle is transporting the item. In some embodiments, the tracking information may include time and location of pickup and delivery as well as details of who received the item or provided the item to the vehicle.);
continuously update the plurality of route schedules based at least in part on the real-time GPS information received form the plurality of vehicles ([047] The vehicle locations may be determined via GPS or any similar location determining means when the vehicles 110a-b are transporting an item for the delivery system 100 or are otherwise associated with the delivery system 100. [0099] FIG. 8 is a block diagram of an exemplary delivery vehicle. The delivery vehicle 110 shown in FIG. 8 may be an exemplary embodiment of the delivery vehicles 110a-b shown in FIG. 1. The exemplary delivery vehicle 110 includes a global positioning system (GPS) receiver 805, vehicle navigation component 810, vehicle route database 812, a vehicle control component 815, and a radio link 820. The radio link 820 may enable one or more of the GPS receiver 805, vehicle navigation component 810, or vehicle control component 815 to communicate wirelessly with other components of the disclosed methods and systems, such as any of the components shown in FIG. 2. [0100] The GPS receiver 805 may receive GPS signals from GPS satellites to determine a position of the vehicle 110. This information may be reported, via the radio link provided via radio link component 820, to for example, the vehicle location management component 220 in some aspects. This may enable the disclosed methods and systems to maintain a current record of a location of the vehicle 110, and of multiple delivery vehicles, such as the vehicles 110a-b of FIG. 1, such that an appropriate vehicle can be selected to perform an on-demand transaction based, in part, on the vehicle's respective location. );
detect, from the monitoring an exception having a potential to impact a route schedule of the plurality of route schedules before the exception causes a delay (([054] In some embodiments, the vehicle route control component 230 may generate a new route with a threshold minimum deviation from the existing vehicle route, wherein the threshold minimum route includes a deviation that is less than a threshold value. In some embodiments, the threshold value may change based on the vehicles identified as being available to transport the item, as will be explained in further detail herein. [0055] In some embodiments, updating the existing vehicle route may comprise obtaining the existing vehicle route from a navigation or similar system of the vehicle 110 when the vehicle is the first-party vehicle 110a or the third-party vehicle 110b. In some embodiments, updating of the vehicle route may only occur after the vehicle 110 accepts the transportation of the item (for example, for the third-party vehicle 110b) or is assigned the transportation of the item (for the first-party vehicle 110a). The Examiner interprets the exception as a new shipment within the route having a potential to impact the route before the driver can accept the exception (i.e. new shipment).);
identify, a plurality of resolutions to the exception wherein the plurality of resolutions reduces or eliminates the potential to impact the route schedule, and wherein the plurality of resolutions comprises at least one of (i) automatically sending a message to a device scheduling or monitoring the route or (ii) automatically adjusting a remainder of the route schedule after the exception is detected when it is determined that the remainder of the route will be impacted by the exception ([054] In some embodiments, the vehicle route control component 230 may generate a new route with a threshold minimum deviation from the existing vehicle route, wherein the threshold minimum route includes a deviation that is less than a threshold value. In some embodiments, the threshold value may change based on the vehicles identified as being available to transport the item, as will be explained in further detail herein. [0055] In some embodiments, updating the existing vehicle route may comprise obtaining the existing vehicle route from a navigation or similar system of the vehicle 110 when the vehicle is the first-party vehicle 110a or the third-party vehicle 110b. In some embodiments, updating of the vehicle route may only occur after the vehicle 110 accepts the transportation of the item (for example, for the third-party vehicle 110b) or is assigned the transportation of the item (for the first-party vehicle 110a). [0057] Selection of the vehicle 110 by the request servicing component 205 to satisfy a user request may be based on various aspects of the user request and/or of the vehicle 110. For example, selection of the vehicle 110 may be based on the operator of the vehicle 110, such as whether the vehicle 110 is a first-party vehicle 110a or a third-party vehicle 110b. The first-party vehicle 110a may be associated with the delivery system 100 and may provide pickup and/or delivery services based on terms of a contract. In some aspects, the contract specifies a maximum deviation of vehicle operator work day lengths or scheduled routes specified by an employer of the operators. For example, there may be limits on a number of hours or an amount of work beyond a contracted amount that the operators are allowed to work. Alternatively, or additionally, there may be limits on a distance that an operator and corresponding vehicle is able to travel. In some embodiments, these maximum deviations include maximum time or maximum distance deviations from the original or scheduled routes. The maximum deviation for a particular operator and/or vehicle may be stored in an operator database 241. The operator management component 240 may consult the operator database 241 to determine maximum deviations allowed under contract for one or more operators/vehicles 110 for consideration by the request servicing component 205 in assigning the user request. This information may be used when selecting the first-party vehicle 110a, and thus an operator, to perform a particular user request. The selection may ensure, in some aspects, that assigning a particular on-demand request (i.e., the item pickup and/or delivery request) to a particular vehicle/operator will not violate the terms of the corresponding contract, as defined by the operator database 241. In some embodiments, the operator database 241 may be the same database as one or both of the vehicle database 221 and the inventory database 226 or another database. );
select one or more resolutions from the plurality of resolutions based on a severity of the potential to impact the route schedule ([0041] The disclosed methods and systems may determine whether a delivery vehicle 110 (for example, one of the delivery vehicles 110a-b) of one of the available transportation and/or delivery services that service the geographic region 105 can satisfy the customer's request. The determination may be based on a number of conditions, such as an availability of the vehicles 110 (for example, from the various transportation and delivery services), the current locations of each of the vehicles 110a-b, the planned routes through the geographic region 105 of the vehicles 110a-b, the locations (for example, pickup and delivery locations) involved in the customer's request, item size, item type, customer preferences or specific constraints, among other conditions. By considering a variety of factors, the disclosed methods and systems may efficiently and effectively satisfy the request of the customer 140.) and
proactively reduce or eliminate the potential to impact the route schedule by automatically implementing the one or more resolutions to the exception ([0013] In some embodiments, the method further comprises determining a minimum deviation route of the identified delivery vehicle based on an original route of the identified delivery vehicle and updating the original route to include the minimum deviation route. [0023] In some embodiments, the processor circuit is further configured to determine a minimum deviation route of the identified delivery vehicle based on an original route of the identified delivery vehicle and updating the original route to include the minimum deviation route. Claims: 10. The method of claim 1, further comprising determining a minimum deviation route of the identified delivery vehicle based on an original route of the identified delivery vehicle and updating the original route to include the minimum deviation route. [0057] Selection of the vehicle 110 by the request servicing component 205 to satisfy a user request may be based on various aspects of the user request and/or of the vehicle 110. For example, selection of the vehicle 110 may be based on the operator of the vehicle 110, such as whether the vehicle 110 is a first-party vehicle 110a or a third-party vehicle 110b. The first-party vehicle 110a may be associated with the delivery system 100 and may provide pickup and/or delivery services based on terms of a contract. In some aspects, the contract specifies a maximum deviation of vehicle operator work day lengths or scheduled routes specified by an employer of the operators. For example, there may be limits on a number of hours or an amount of work beyond a contracted amount that the operators are allowed to work. Alternatively, or additionally, there may be limits on a distance that an operator and corresponding vehicle is able to travel. In some embodiments, these maximum deviations include maximum time or maximum distance deviations from the original or scheduled routes. The maximum deviation for a particular operator and/or vehicle may be stored in an operator database 241. The operator management component 240 may consult the operator database 241 to determine maximum deviations allowed under contract for one or more operators/vehicles 110 for consideration by the request servicing component 205 in assigning the user request. This information may be used when selecting the first-party vehicle 110a, and thus an operator, to perform a particular user request. The selection may ensure, in some aspects, that assigning a particular on-demand request (i.e., the item pickup and/or delivery request) to a particular vehicle/operator will not violate the terms of the corresponding contract, as defined by the operator database 241. In some embodiments, the operator database 241 may be the same database as one or both of the vehicle database 221 and the inventory database 226 or another database.).
Luckay discloses a system and method for coordinating deliveries and shipments for a plurality of routes wherein the system is able to identify an exception having a potential to impact the route (i.e. a new shipment to add to the route) identify a resolution and eliminate the potential to impact the route by implementing the resolution. However Luckay does not disclose that the system trains an artificial intelligence engine with historical data in order to detect an exception and identify a resolution to the exception based on the historical data.
Newell is introduced to teach a system and method for coordinating shipments for a plurality of routes using historical data to train an artificial intelligence and further teaches:
train an artificial intelligence engine associated with the server computer using historical data comprising data associated with the plurality of route schedules, the plurality of routes, the plurality of vehicles, the plurality of drivers, and past exceptions, to identify at least one resolution of the past exceptions (See Fig. 6 and [0006] Embodiments described herein provide artificial intelligence-based systems and methods to detect delays in a shipping network. Even more particularly, embodiments employ artificial intelligence to detect shipping delays across heterogenous carriers. Embodiments address issues presented by carrier systems that fail to accurately signal when a shipment is delayed past its EDD by using a combination of features to robustly detect shipping delays. Embodiments use a training set of shipping data (e.g., collected for shipments across carriers) to train a machine learning (ML) model. This training set may be developed by applying transformations on an acquired set of shipping data. The ML model is then trained with this training set. The trained ML model may be applied to newly acquired and transformed shipping data to predict if a delay will occur. [0007] According to one embodiment, ML models are trained to detect whether a shipment will miss its estimated delivery date (EDD) using in-flight snapshots of historical shipments and the eventual outcomes of those shipments. [0022] FIG. 6 is a diagrammatic representation of one embodiment of a record of a historical shipment and a set of in-flight snapshots of the historical shipment. [0030] Over time, a rich set of data is acquired across shipments and carriers. This acquired data for historical shipments may be transformed such that the data across shipments and carriers can be used as a training set to train a machine learning (ML) model. ML models can be trained on in-flight snapshots of historical shipments and the eventual outcome of each of the historical shipments considered—that is, whether the shipment missed it's EDD. The input features extracted for a historical shipment and used to train the model can include data about the “current” status of a historical shipment from the perspective of one or more times in the life of the shipment based on information from the carrier tracking services and, in some cases, whether information was not received from the carrier tracking services when it may have been expected to be received. Examples of input features include: carrier, service level, time since the last tracking event, type of last tracking event, time of day of last tracking event, day of week of last tracking event, time remaining to the current EDD, package weight, location of the last tracking event, distance from the last known location to the destination, and other features. );
identify, using the trained artificial intelligence engine, a resolution to the exception based on analysis of the historical data ([0074] Carriers often provide EDDs for shipments and prediction service 136 can be configured to detect shipments that will miss their EDDs. According to one embodiment, prediction service 136 may include or utilize ML model 140 trained on a set of input features to detect shipments that will miss their EDDs. For example, ML model 140 may be trained to classify shipments as “on-time” or “delayed” and output a delay risk score (e.g., a probability that the shipment should be classified “delayed”). The shipment information and the delay risk score for the in-progress shipment can be stored in a database indexed for a web application. According to one embodiment, the in-progress shipment is determined to be at risk of missing its estimated delivery date if the delay risk score meets a configurable threshold (say, 0.5, 0.75 or another threshold). [0075] As discussed above, shipping management system 120 can learn about shipments from a variety of sources and the shipments can be tracked via carrier APIs 151 or other mechanisms. Shipment data can be regularly sent to or otherwise regularly analyzed by prediction service 136. According to one embodiment, prediction service 136 executes ML model 140 to infer a delay risk score for the shipment. The delay risk score and shipment attributes can be stored in a database and indexed to a web application. Shipments that have a delay risk score greater than a threshold may be identified as being at risk. ).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled to specifically train and use artificial intelligence based on historical data to identify a resolution to an exception since such improvement on the system of Luckay provides the well-known benefits that offers using artificial intelligence such as allowing the system to analyze historical data to improve the decision making of the system and reduce human error. Further see Newell [006].
Regarding claims 2 and 13, Luckay discloses:
automatically adjusting a remainder of the route schedule after the exception is detected when it is determined that the remainder of the route will be impacted by the exception ([0013] In some embodiments, the method further comprises determining a minimum deviation route of the identified delivery vehicle based on an original route of the identified delivery vehicle and updating the original route to include the minimum deviation route. [0023] In some embodiments, the processor circuit is further configured to determine a minimum deviation route of the identified delivery vehicle based on an original route of the identified delivery vehicle and updating the original route to include the minimum deviation route. Claims: 10. The method of claim 1, further comprising determining a minimum deviation route of the identified delivery vehicle based on an original route of the identified delivery vehicle and updating the original route to include the minimum deviation route. [0057] Selection of the vehicle 110 by the request servicing component 205 to satisfy a user request may be based on various aspects of the user request and/or of the vehicle 110. For example, selection of the vehicle 110 may be based on the operator of the vehicle 110, such as whether the vehicle 110 is a first-party vehicle 110a or a third-party vehicle 110b. The first-party vehicle 110a may be associated with the delivery system 100 and may provide pickup and/or delivery services based on terms of a contract. In some aspects, the contract specifies a maximum deviation of vehicle operator work day lengths or scheduled routes specified by an employer of the operators. For example, there may be limits on a number of hours or an amount of work beyond a contracted amount that the operators are allowed to work. Alternatively, or additionally, there may be limits on a distance that an operator and corresponding vehicle is able to travel. In some embodiments, these maximum deviations include maximum time or maximum distance deviations from the original or scheduled routes. The maximum deviation for a particular operator and/or vehicle may be stored in an operator database 241. The operator management component 240 may consult the operator database 241 to determine maximum deviations allowed under contract for one or more operators/vehicles 110 for consideration by the request servicing component 205 in assigning the user request. This information may be used when selecting the first-party vehicle 110a, and thus an operator, to perform a particular user request. The selection may ensure, in some aspects, that assigning a particular on-demand request (i.e., the item pickup and/or delivery request) to a particular vehicle/operator will not violate the terms of the corresponding contract, as defined by the operator database 241. In some embodiments, the operator database 241 may be the same database as one or both of the vehicle database 221 and the inventory database 226 or another database.).
Regarding claims 3 and 14, Newell teaches:
determine, using the trained artificial intelligence engine, a score indicating an impact of the exception on a remainder of the route schedule based on the analysis of the historical data, wherein the one or more resolutions to the exception includes taking a corrective action associated with the route schedule or a route corresponding to the route schedule when the score is above a threshold ([007] A shipping management system can monitor in-progress shipments and assign them a risk score periodically based on the inference of the ML model. According to one embodiment, when the risk score exceeds a certain threshold, the shipment is identified as one predicted to miss its EDD.[010] The ML model can be executed on the set of predictive features for the in-progress shipment to output an inference for the in-progress shipment. The inference may classify the shipment as, for example, “on-time” (the shipment is predicted to meet its estimated delivery date) or “delayed” (the shipment is predicted not to meet its estimated delivery date). In some embodiments, the model outputs a raw probability score that a shipment fits a particular class. The probability score may be used to identify shipments that are at risk of missing their EDDs. The probability that a shipment is “delayed” may be referred to as a delay risk score. The shipment information and the delay risk score for the in-progress shipment can be stored in a database indexed for a web application. According to one embodiment, the in-progress shipment is determined to be at risk of missing its estimated delivery date if the delay risk score exceeds a threshold. [0031] The shipping management system monitors in-progress shipments being tracked by the system and periodically assigns them risk scores based on inferences of the ML model. According to one embodiment, an ML model can be executed on predictive features extracted from an in-progress shipment to detect whether the shipment will miss its assigned EDD and output an indicator of the risk that the shipment will miss its EDD. When the risk score exceeds a certain threshold, the shipment can be identified as one predicted to miss its EDD. Embodiments may thus detect shipments that will miss their EDDs before that EDD has passed, which allows shippers and recipients to proactively understand and recover potential delays. [0074] Carriers often provide EDDs for shipments and prediction service 136 can be configured to detect shipments that will miss their EDDs. According to one embodiment, prediction service 136 may include or utilize ML model 140 trained on a set of input features to detect shipments that will miss their EDDs. For example, ML model 140 may be trained to classify shipments as “on-time” or “delayed” and output a delay risk score (e.g., a probability that the shipment should be classified “delayed”). The shipment information and the delay risk score for the in-progress shipment can be stored in a database indexed for a web application. According to one embodiment, the in-progress shipment is determined to be at risk of missing its estimated delivery date if the delay risk score meets a configurable threshold (say, 0.5, 0.75 or another threshold). ).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention as filled to determine a score indicating an impact of the exception on a remainder of the route schedule, wherein the resolution to the exception includes taking a corrective action associated with the route or the route schedule if the score is above a threshold, and wherein the resolution to the exception includes sending a warning to a device scheduling or monitoring the route when the score is below the threshold since such modification in the system and method of Luckay provides the known benefits presented by Newell, including identifying shipments or deliveries as being predicted to miss an estimated delivery time before the delivery time passes in order to proactively understand and recover potential delays.
Regarding claims 4 and 15, Newell teaches:
determine, using the trained artificial intelligence engine, a score indicating an impact of the exception on a remainder of the route schedule based on the analysis of the historical data, wherein the one or more resolutions to the exception includes sending a warning to a device scheduling or monitoring a route corresponding to the route schedule when the score is below a threshold ([007] A shipping management system can monitor in-progress shipments and assign them a risk score periodically based on the inference of the ML model. According to one embodiment, when the risk score exceeds a certain threshold, the shipment is identified as one predicted to miss its EDD.[010] The ML model can be executed on the set of predictive features for the in-progress shipment to output an inference for the in-progress shipment. The inference may classify the shipment as, for example, “on-time” (the shipment is predicted to meet its estimated delivery date) or “delayed” (the shipment is predicted not to meet its estimated delivery date). In some embodiments, the model outputs a raw probability score that a shipment fits a particular class. The probability score may be used to identify shipments that are at risk of missing their EDDs. The probability that a shipment is “delayed” may be referred to as a delay risk score. The shipment information and the delay risk score for the in-progress shipment can be stored in a database indexed for a web application. According to one embodiment, the in-progress shipment is determined to be at risk of missing its estimated delivery date if the delay risk score exceeds a threshold. [0031] The shipping management system monitors in-progress shipments being tracked by the system and periodically assigns them risk scores based on inferences of the ML model. According to one embodiment, an ML model can be executed on predictive features extracted from an in-progress shipment to detect whether the shipment will miss its assigned EDD and output an indicator of the risk that the shipment will miss its EDD. When the risk score exceeds a certain threshold, the shipment can be identified as one predicted to miss its EDD. Embodiments may thus detect shipments that will miss their EDDs before that EDD has passed, which allows shippers and recipients to proactively understand and recover potential delays. [0074] Carriers often provide EDDs for shipments and prediction service 136 can be configured to detect shipments that will miss their EDDs. According to one embodiment, prediction service 136 may include or utilize ML model 140 trained on a set of input features to detect shipments that will miss their EDDs. For example, ML model 140 may be trained to classify shipments as “on-time” or “delayed” and output a delay risk score (e.g., a probability that the shipment should be classified “delayed”). The shipment information and the delay risk score for the in-progress shipment can be stored in a database indexed for a web application. According to one embodiment, the in-progress shipment is determined to be at risk of missing its estimated delivery date if the delay risk score meets a configurable threshold (say, 0.5, 0.75 or another threshold). ).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention as filled to determine, using the trained artificial intelligence engine, a score indicating an impact of the exception on a remainder of the route schedule based on the analysis of the historical data, wherein the resolution to the exception includes sending a warning to a device scheduling or monitoring the route when the score is below a threshold since such modification in the system and method of Luckay provides the known benefits presented by Newell, including identifying shipments or deliveries as being predicted to miss an estimated delivery time before the delivery time passes in order to proactively understand and recover potential delays.
Regarding claims 5-6 and 16, Luckay discloses:
a dispatch control center device ( [0039] FIG. 1 is an overview diagram of a geographic region 105 in which a localized delivery system (not shown) is implemented. The delivery system 100 comprises or utilizes an automated system, a software interface, or a live attendant, for example. The delivery system 100 includes a plurality of delivery vehicles 110a-b traveling over the geographic region 105. At any particular time, a first delivery vehicle 110a (for example a first-party vehicle 110a) may be located at a first position 130a while a second delivery vehicle 110b (for example a third-party vehicle 110b) may be located at a second position 130b. In some embodiments, the plurality of delivery vehicles 110a-b are part of one or more transportation services and travel according to one or more delivery routes that are static and predetermined or dynamic and variable. In some embodiments, one or more other delivery vehicles 110 become available or one or more of the delivery vehicles 110a-b become unavailable dynamically while the delivery system 100 is operating. [0043] In some aspects, the request may be received from a call center 215, with the customer 140 calling into the call center 215 to indicate their request. ).
Newell further teaches:
identifying the exception on a dispatch control center device using one or more sensory cues, wherein the dispatch control center device is configured to display historic data associated with a selected route, vehicle, or driver (Figures 8 and 9 and [0135] As discussed above, in-progress shipments may be evaluated using a trained ML model to determine delay risk scores. Shipments having delay risk scores that exceed a configurable threshold may be marked as at risk of missing a date (e.g., EDD or promise date). Shipping management system 120 can provide a UI that allows a user associated with an account to view shipments associated with the account. For example, shipping management system 120 can provide a user interface to allow a user to view the details of individual shipments that are marked as “at risk.” Further shipping management system may provide various views. FIG. 8, for example, illustrates one embodiment of a user interface 800 that allows the user to view for example statistics on shipments that are considered at risk of missing the EDD. FIG. 9 provides an example of a user interface 900 that aggregates information across carriers to allow the user to view which carriers/service levels have the most shipments for the user that are predicted to miss the EDD.)
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled to identifying the exception on a dispatch control center device using one or more sensory cues, wherein the dispatch control center device is configured to display historic data associated with a selected route, vehicle, or driver since such improvement on the system of Luckay provides the well-known benefits allowing the users of the system to view statistics on shipments that are considered at risk of missing the estimated shipping date.
Regarding claim 7, Luckay disclose:
a dispatch control center device configured to display information associated with one or more of the plurality of vehicles and one or more of the plurality of routes ([0039] FIG. 1 is an overview diagram of a geographic region 105 in which a localized delivery system (not shown) is implemented. The delivery system 100 comprises or utilizes an automated system, a software interface, or a live attendant, for example. The delivery system 100 includes a plurality of delivery vehicles 110a-b traveling over the geographic region 105. At any particular time, a first delivery vehicle 110a (for example a first-party vehicle 110a) may be located at a first position 130a while a second delivery vehicle 110b (for example a third-party vehicle 110b) may be located at a second position 130b. In some embodiments, the plurality of delivery vehicles 110a-b are part of one or more transportation services and travel according to one or more delivery routes that are static and predetermined or dynamic and variable. In some embodiments, one or more other delivery vehicles 110 become available or one or more of the delivery vehicles 110a-b become unavailable dynamically while the delivery system 100 is operating. [0043] In some aspects, the request may be received from a call center 215, with the customer 140 calling into the call center 215 to indicate their request. [0040] While the vehicles 110a-b are located at the positions 130a-b and/or traveling along their corresponding delivery routes (not shown), a customer 140 may contact the delivery system 100 operating in the geographic region 105, to request or coordinate a pickup and/or delivery of an item or good. In some embodiments, the customer 140 may contact the delivery system 100 via a mobile computing device (not shown), for example via an application or a web browser on a smartphone, via another computing device (for example, a desktop computer, and so forth), via a phone call, and so forth. In some embodiments, the customer 140 may contact the delivery system 100 via a merchant, supplier, or broker, who has access to the delivery system 100. The coordinated pickup and/or delivery may include one or more of a pick-up of the item or good from a first location (such as a location of the customer 150) and delivery of the item or good to a second location. In some embodiments, the coordinated pickup and/or delivery does not involve the customer location 150. The coordinated pickup and delivery may include customer preferences and/or specific time constraints, geography constraints, vehicle size constraints, transportation constraints, and the like. For example, the customer 140 may request pickup and/or delivery by a certain time of day, transportation along a certain route, transportation by a particular transportation mode, or method, transportation of a perishable item, or transportation of a large or irregularly shaped item which cannot fit in every vehicle 110a-b. ).
Regarding claims 8 and 17, Luckay disclose:
wherein the exception is based on one or more of the driver failing to clock in at a scheduled time, the vehicle departing a vehicle storage facility after the scheduled time, the vehicle arriving at a first stop on the route for the vehicle, the vehicle being late to a scheduled stop, or not having the driver assigned to the vehicle ([0054] In some embodiments, the determination of whether to add the pickup and/or delivery location(s) as waypoints or intermediate destinations or as continuing destinations is based on an impact adding these locations would have on an efficiency of the existing vehicle route or an impact adding these locations would have on travel time, arrival time, distance, etc., of the first-party vehicle 110a to its ultimate destination and any timing constraints of transporting the item per the user request. In some embodiments, the vehicle route control component 230 may generate a new route with a threshold minimum deviation from the existing vehicle route, wherein the threshold minimum route includes a deviation that is less than a threshold value. In some embodiments, the threshold value may change based on the vehicles identified as being available to transport the item, as will be explained in further detail herein. [0055] In some embodiments, updating the existing vehicle route may comprise obtaining the existing vehicle route from a navigation or similar system of the vehicle 110 when the vehicle is the first-party vehicle 110a or the third-party vehicle 110b. In some embodiments, updating of the vehicle route may only occur after the vehicle 110 accepts the transportation of the item (for example, for the third-party vehicle 110b) or is assigned the transportation of the item (for the first-party vehicle 110a).).
Regarding claims 9 and 18, Luckay disclose:
wherein automatically implementing the one or more resolutions is based on a time threshold for performing a ride service request according to the route schedule ([0057] Selection of the vehicle 110 by the request servicing component 205 to satisfy a user request may be based on various aspects of the user request and/or of the vehicle 110. For example, selection of the vehicle 110 may be based on the operator of the vehicle 110, such as whether the vehicle 110 is a first-party vehicle 110a or a third-party vehicle 110b. The first-party vehicle 110a may be associated with the delivery system 100 and may provide pickup and/or delivery services based on terms of a contract. In some aspects, the contract specifies a maximum deviation of vehicle operator work day lengths or scheduled routes specified by an employer of the operators. For example, there may be limits on a number of hours or an amount of work beyond a contracted amount that the operators are allowed to work. Alternatively, or additionally, there may be limits on a distance that an operator and corresponding vehicle is able to travel. In some embodiments, these maximum deviations include maximum time or maximum distance deviations from the original or scheduled routes.).
Regarding claims 11 and 19, Luckay disclose:
monitor the plurality of vehicles, the plurality of routes and the corresponding route schedules to estimate a location of the plurality of vehicles at a given time ([0039] FIG. 1 is an overview diagram of a geographic region 105 in which a localized delivery system (not shown) is implemented. The delivery system 100 comprises or utilizes an automated system, a software interface, or a live attendant, for example. The delivery system 100 includes a plurality of delivery vehicles 110a-b traveling over the geographic region 105. At any particular time, a first delivery vehicle 110a (for example a first-party vehicle 110a) may be located at a first position 130a while a second delivery vehicle 110b (for example a third-party vehicle 110b) may be located at a second position 130b. [0052] The vehicle route control component 230 may store, monitor, and update a designated route of the vehicles 110a-b based on the pickup and delivery locations(s) of the user request. For example, each of the vehicles 110a-b may travel within the geographic region 105 according to a route that is stored in and monitored by the vehicle route control component 230. In some embodiments, the vehicle route control component 230 may work in conjunction with the vehicle location management component 220 to monitor the routes for the vehicles 110a-b. In some embodiments, if the vehicle route control component 230 determines that a vehicle 110 is off its route by a threshold amount, the vehicle route control component 230 may generate an alarm or an alert. [0053] In some embodiments, the vehicle route control component 230 may monitor routes for all first-party vehicles 110a and all third-party vehicles 110b that are transporting items according to user requests.);
receive real-time information from vehicle devices, wherein a vehicle device is associated with each one of the plurality of vehicles ([0039] FIG. 1 is an overview diagram of a geographic region 105 in which a localized delivery system (not shown) is implemented. The delivery system 100 comprises or utilizes an automated system, a software interface, or a live attendant, for example. The delivery system 100 includes a plurality of delivery vehicles 110a-b traveling over the geographic region 105. At any particular time, a first delivery vehicle 110a (for example a first-party vehicle 110a) may be located at a first position 130a while a second delivery vehicle 110b (for example a third-party vehicle 110b) may be located at a second position 130b. In some embodiments, the plurality of delivery vehicles 110a-b are part of one or more transportation services and travel according to one or more delivery routes that are static and predetermined or dynamic and variable. In some embodiments, one or more other delivery vehicles 110 become available or one or more of the delivery vehicles 110a-b become unavailable dynamically while the delivery system 100 is operating. [0040] While the vehicles 110a-b are located at the positions 130a-b and/or traveling along their corresponding delivery routes (not shown), a customer 140 may contact the delivery system 100 operating in the geographic region 105, to request or coordinate a pickup and/or delivery of an item or good. In some embodiments, the customer 140 may contact the delivery system 100 via a mobile computing device (not shown), for example via an application or a web browser on a smartphone, via another computing device (for example, a desktop computer, and so forth), via a phone call, and so forth. In some embodiments, the customer 140 may contact the delivery system 100 via a merchant, supplier, or broker, who has access to the delivery system 100. The coordinated pickup and/or delivery may include one or more of a pick-up of the item or good from a first location (such as a location of the customer 150) and delivery of the item or good to a second location. In some embodiments, the coordinated pickup and/or delivery does not involve the customer location 150. The coordinated pickup and delivery may include customer preferences and/or specific time constraints, geography constraints, vehicle size constraints, transportation constraints, and the like. For example, the customer 140 may request pickup and/or delivery by a certain time of day, transportation along a certain route, transportation by a particular transportation mode, or method, transportation of a perishable item, or transportation of a large or irregularly shaped item which cannot fit in every vehicle 110a-b. ); and
continuously update the estimated location of the plurality of vehicles at the given time based on the real-time information received from the vehicle devices ([0041] The disclosed methods and systems may determine whether a delivery vehicle 110 (for example, one of the delivery vehicles 110a-b) of one of the available transportation and/or delivery services that service the geographic region 105 can satisfy the customer's request. The determination may be based on a number of conditions, such as an availability of the vehicles 110 (for example, from the various transportation and delivery services), the current locations of each of the vehicles 110a-b, the planned routes through the geographic region 105 of the vehicles 110a-b, the locations (for example, pickup and delivery locations) involved in the customer's request, item size, item type, customer preferences or specific constraints, among other conditions. By considering a variety of factors, the disclosed methods and systems may efficiently and effectively satisfy the request of the customer 140.).
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Luckay (US Patent Publication 2020/0286021) in view of Newell (US Patent Publication 2022/0092530) and Sheeran (US Patent Publication 2023/0185502).
Regarding claim 10, Luckay does not explicitly disclose:
wherein an element of the historical data associated with one or more of the plurality of route schedules, the plurality of routes, the plurality of vehicles, the plurality of drivers, or the exception is associated with a coefficient indicative of an age of the element of the historical data, wherein the element of the historical data is weighed using the coefficient.
Sheeran, which is related to mail shipment or delivery, is introduced to teach a system that similar to Luckay and Newell monitors delivery by determining schedules and estimating arrival times. Sheeran further teaches that the historical data used to estimating arrivals time takes into consideration the oldness of the data.
Sheeran further teaches:
wherein an element of the historical data associated with one or more of the plurality of route schedules, the plurality of routes, the plurality of vehicles, the plurality of drivers, or the exception is associated with a coefficient indicative of an age of the element of the historical data, wherein the element of the historical data is weighed using the coefficient ([0029] As discussed above, estimated delivery times can be determined based on real time, or near-real time, as well as historical tracking data obtained from the tracking of mail pieces passed through the system or from alternative in-house or third-party tracking software and reporting. In certain embodiments, estimated delivery times for various routes can be determined from weighted historical and real time, or near-real time, data where more recent data is assigned a greater weight to account for changes over time. ).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filed to include wherein an element of the historical data associated with one or more of the route schedule, the route, the vehicle, the driver, or the exception is associated with a coefficient indicative of an age of the element of the historical data, wherein the element of the historical data is weighed using the coefficient since taking into consideration the age of the historical data provides the known benefit of being able to account for changes in the data that occur over time as disclosed by Sheeran [029].
Response to Arguments
Applicant’s arguments, see remarks, filed 05/26/2026, with respect to 35 USC 101 have been fully considered and are persuasive. The rejection of claims 1-20 has been withdrawn.
Examiner is persuaded by Applicant’s amendments. The claims do not merely analyze vehicle location information to determine the existence or severity of an exception. Rather, the claims use GPS technology as part of a control process that modifies the operation of the vehicle by rerouting the vehicle based on the determined severity of the exception. The determination is integrated into a practical application that effects a real world change in the operation of the vehicle by causing the vehicle to follow a different route. The GPS technology is not merely a generic source of data used to perform the abstract idea, but used in conjunction with vehicle navigation to implement the routing modification of the vehicle.
Regarding the previously presented 35 USC 103, Applicant argues:
“ First, the cited references do not teach or suggest using a trained AI engine to identify an exception that has a potential to impact the route schedule, and identifying a resolution that proactively eliminates or reduces the impact to the route schedule. Indeed, the Examiner admits, on page 20 of the Office Action, that Luckay does not disclose training an artificial intelligence engine with historical data in order to identify a resolution to the exception based on the historical data. The Examiner introduces Newell to remedy this deficiency. Newell uses an ML model to predict whether a package in transit will be delayed. At [0002], Newell explains that AI systems are provided to detect delays in final mile shipping networks. Newell identifies a package that is likely to be delayed. However, and notably, Newell is entirely silent about identifying a resolution to reduce or eliminate the delay, and automatically implementing "one or more (selected) resolutions from the plurality of resolutions based on a severity of the potential to impact the route schedule". Examiner respectfully disagrees. Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. In the instant application, Luckay discloses identifying the exception and the resolution to the exception, however does not uses a trained artificial intelligence engine using historical data to identify the resolution. For that reason, Newell is introduced to show that it is well-known in the art of route scheduling and monitoring to use an artificial intelligence engine using historical data to identify an exception (such as a delay in route).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Khasis, US 20180003516, METHODS AND SYSTEMS FOR DETECTING AND VERIFYING ROUTE DEVIATIONS. [0049] The system may access a schedule data for a transit route for a predetermined time and geographic area. A scheduled route may be a series of estimated times paired with geographic locations for transit destinations implemented by an administrator of the system or a self-learning machine. An average historical route may be an average of recorded times paired with averaged geographic locations from past routes on the transit system. A route and route deviation storing means may be used to store route deviations comparing deviated scheduled routes and deviated average historical routes, and may allow the system to learn from the stored information when a vehicle travels on a same or similar route again, further preventing a vehicle from deviating from a generated route. Once a deviation is identified, the data may be utilized to monitor and analyze drivers and vehicles. The deviating location points may be used to construct a new route leg, a new stop, or a new schedule for the transit route, if a positive value is determined for the deviation. [0073] A scheduled route may be a series of estimated times paired with geographic locations for transit destinations implemented by an administrator of the system or a self-learning machine. An average historical route may be an average of recorded times paired with averaged geographic locations from past routes on the transit system. A route and route deviation storing means may be used to store route deviations compared to scheduled routes and average historical routes, and may allow the system to learn from the stored information when a vehicle travels on a same or similar route again, further preventing a vehicle from deviating from one or more generated routes. Once the deviation is identified, the data may be utilized to monitor and analyze drivers and vehicles. The deviating location points may be used to construct a new route leg, a new stop, or a new schedule for the transit route.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 MARIA C SANTOS-DIAZ whose telephone number is (571)272-6532. The examiner can normally be reached Monday-Friday 8:00AM-5:00PM.
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, Sarah Monfeldt can be reached at 571-270-1833. 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.
/MARIA C SANTOS-DIAZ/Primary Examiner, Art Unit 3629
Prosecution Insights