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 Claims
The following is a non-final Office Action in response to claims filed 07/08/2025.
Claims 1-20 are pending.
Claims 1-20 have been examined.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07/08/2025 and 12/26/2025 are being considered by the examiner.
Double Patenting
Claim 1-20 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1 of copending Application No. 18/774,436. Although the claims at issue are not identical, they are not patentably distinct from each other because claim 1 of the pending application is completely taught by application 18/774,436.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Regarding claims 1, 12 and 20, Claims 1, 12 and 20 of Application 18/744,436 discloses:
a system (claim 1);
a method (claim 12); and
a non-transitory computer-readable medium storing instructions that, when executed on a server computer, cause the server computer to perform steps (claim 20)
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 to (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 to):
determine a plurality of routes and corresponding route schedules for a plurality of ride service requests (determine a plurality of routes and corresponding route schedules for a plurality of ride service requests );
assign a plurality of vehicles to service each one of the plurality of routes (assign a plurality of vehicles to service each one of the plurality of routes);
for each one of the plurality of routes, assign a vehicle among the plurality of vehicles to a driver to perform a route according to a route schedule to which the vehicle is assigned (for each one of the plurality of routes, assign a vehicle among the plurality of vehicles to a driver to perform a route according to a route schedule to which the vehicle is assigned);
monitor the plurality of vehicles, the plurality of routes and the corresponding route schedules (monitor the plurality of vehicles, the plurality of routes and the corresponding route schedules);
train an artificial intelligence engine associated with the server computer using historical data associated with one or more of the route schedule, the route, the vehicle, the driver, and past exceptions (train an artificial intelligence engine associated with the server computer using historical data associated with one or more of the route schedule, the route, the vehicle, the driver, and past exceptions);
detect, using the trained artificial intelligence engine, an exception having a potential to impact the route schedule before the exception causes in a delay (detect, using the trained artificial intelligence engine, an exception having a potential to impact the route schedule before the exception causes in a delay);
identify, using the trained artificial intelligence engine, a resolution to the exception based on analysis of the historical data, wherein the resolution reduces or eliminates the potential to impact the route schedule (identify, using the trained artificial intelligence engine, a resolution to the exception based on analysis of the historical data, wherein the resolution reduces or eliminates the potential to impact the route schedule); and
proactively reduce or eliminate the potential to impact the route schedule by automatically implement implementing the resolution to the exception (proactively reduce or eliminate the potential to impact the route schedule by automatically implement implementing the resolution to the exception).
Regarding claims 2 and 13, Claim 1 of Application 18/744,436 discloses:
wherein the resolution includes 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 (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).
Regarding claims 3 and 14, Claim 3 of Application 18/744,436 discloses:
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 taking a corrective action associated with the route or the route schedule when the score is above a threshold (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 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.).
Regarding claims 4 and 15, Claim 3 of Application 18/744,436 discloses:
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 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 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.).
Regarding claims 5 and 16, Claim 5 of Application 18/744,436 discloses:
identify the exception on a dispatch control center device using one or more sensory cues (identify the exception on the dispatch control center device using one or more sensory cues.).
Regarding claim 6, Claim 6 of Application 18/744,436 discloses:
wherein the dispatch control center device is configured to display historic data associated with a selected route, vehicle, or driver (wherein the dispatch control center device is configured to display historic data associated with a selected route, vehicle, or driver.).
Regarding claim 7, Claim 5 of Application 18/744,436 discloses:
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 (display information associated with each one of the plurality of vehicles and the plurality of routes on a dispatch control center device).
Regarding claims 8 and 17, Claim 2 of Application 18/744,436 discloses:
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 (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.).
Regarding claims 9 and 18, Claim 10 of Application 18/744,436 discloses:
wherein automatically implementing the resolution is based on a time threshold for performing a ride service request according to the route schedule (wherein automatically implementing the resolution is based on a time threshold for performing a ride service request according to the route schedule.).
Regarding claim 10, Claim 11 of Application 18/744,436 discloses:
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 (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.).
Regarding claims 11 and 19, Claim 11 of Application 18/744,436 discloses:
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 (monitor the plurality of vehicles, the plurality of routes and the corresponding route schedules; maintain estimated global positioning system ("GPS") information and estimated time of arrival ("ETA") information for each vehicle servicing each one of the plurality of routes);
receive real-time information from vehicle devices, wherein a vehicle device is associated with each one of the plurality of vehicles (receive real-time information from vehicle devices, wherein a vehicle device is associated with each one of the plurality of vehicles ); 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 (continuously update the estimated GPS information and the estimated ETA information based on the real-time information received from the vehicle devices).
Claim Rejections - 35 USC § 101
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.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claims are directed to an abstract idea without significantly more.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The eligibility analysis in support of these findings is provided below, in accordance with MPEP 2106.
With respect to Step 1 of the eligibility inquiry (as explained in MPEP 2106), it is first noted that the method (claims 1-11), system (claims 12-19 and 20) are directed to at least one potentially eligible category of subject matter (i.e., process and machine, respectively). Thus, Step 1 of the Subject Matter Eligibility test for claims 1-20 is satisfied.
With respect to Step 2A Prong One, it is next noted that the claims recite an abstract idea that falls under the “Mental Processes” and “Certain Methods of Organizing Human Activity” groups within the enumerated groupings of abstract ideas set forth in the MPEP 2106.04 since the claims set forth steps that can be performed in the human mind (e.g., observation, evaluation, judgment, opinion); and managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions).
Claims 1, 12 and 20 recite the abstract idea of identify when a ride service is late or likely to be late and implement resolutions to correct the timing of the ride service [002]. With respect to independent claims 1, 12 and 20 the limitations reciting the abstract idea are indicated in bold below:
determine a plurality of routes and corresponding route schedules for a plurality of ride service requests;
assign a plurality of vehicles to service each one of the plurality of routes;
for each one of the plurality of routes, assign a vehicle among the plurality of vehicles to a driver to perform a route according to a route schedule to which the vehicle is assigned;
monitor the plurality of vehicles, the plurality of routes and the corresponding route schedules;
create a model using historical data associated with one or more of the route schedule, the route, the vehicle, the driver, and past exceptions;
detect an exception having a potential to impact the route schedule before the exception causes in a delay;
identify a resolution to the exception based on an analysis of historical data, wherein the resolution reduces or eliminates the potential to impact the route schedule;
proactively reduce or eliminate the potential to impact the route schedule by automatically implementing the resolution to the exception.
Because the above-noted limitations recite steps falling within the Mental Processes and Certain Methods of Organizing Human Activity, abstract idea groupings of the MPEP 2106.04, they have been determined to recite at least one abstract idea when evaluated under Step 2A Prong One of the eligibility inquiry.
Therefore, because the limitations above set forth activities falling within the “Mental Processes” and “Certain Methods of Organizing Human Activity”, abstract idea groupings described in the MPEP 2106.04, the additional elements recited in the claims are further evaluated, individually and in combination, under Step 2A Prong Two and Step 2B below. Claims 12 and 20 recites similar limitations as claim 1 and are therefore determined to recite the same abstract idea.
With respect to Step 2A Prong Two of the MPEP 2106, the judicial exception is not integrated into a practical application. The additional elements are:
a server computer comprising one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the processors to perform the instructions;
train an artificial intelligence engine; and
a non-transitory computer-readable medium storing instructions.
These additional elements have been evaluated, but fail to integrate the abstract idea into a practical application because they amount to using generic computing elements or computer-executable instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), and merely serve to link the use of the judicial exception to a particular technological environment. See MPEP 2106.05(f) and 2106.05(h).
In addition, these limitations fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Regarding “train an artificial intelligence engine associated with the server computer”, “detect, using the trained artificial intelligence engine”, “identify, using the trained artificial intelligence engine” The examiner views these additional elements as results-oriented steps given that there is no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result are currently present such that this is viewed as equivalent to “apply it” for merely implementing the abstract idea using generic computing components (See Id.).
Accordingly, because the Step 2A Prong One and Prong Two analysis resulted in the conclusion that the claims are directed to an abstract idea, additional analysis under Step 2B of the eligibility inquiry must be conducted in order to determine whether any claim element or combination of elements amount to significantly more than the judicial exception.
With respect to Step 2B of the eligibility inquiry, it has been determined that the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception.
As noted above, the claims as a whole merely describes a method, computer system, and computer program product that generally “apply” the concepts discussed in prong 1 above. (See MPEP 2106.05 f (II)) In particular applicant has recited the computing components at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components. As the court stated in TLI Communications v. LLC v. AV Automotive LLC, 823 F.3d 607, 613 (Fed. Cir. 2016) merely invoking generic computing components or machinery that perform their functions in their ordinary capacity to facilitate the abstract idea are mere instructions to implement the abstract idea within a computing environment and does not add significantly more to the abstract idea. Accordingly, these additional computer components do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea and as a result the claim is not patent eligible.
In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements integrates the abstract idea into a practical application. Their collective functions merely provide generic computer implementation. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a practical application of the abstract idea or that, as an ordered combination, amount to significantly more than the abstract idea itself.
Dependent claims 2-11 and 13-19 recite the same abstract idea as recited in the independent claims, and when evaluated under Step 2A Prong One are found to merely recite details that serve to narrow the same abstract idea recited in the independent claims accompanied by the same generic computing elements or software as those addressed above in the discussion of the independent claims, which is not sufficient to amount to a practical application or add significantly more, or other additional elements that fail to amount to a practical application or add significantly more, as noted above.
Dependent claims 2, 9 and 13, 18 further limits the abstract idea by embellishing the abstract idea and linking the judicial exception to a particular technological environment by introducing the limitation 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 and wherein automatically implementing the resolution is based on a time threshold for performing a ride service request according to the route schedule. Adjusting a route schedule is a manual process until limited by the use of a processor or a server. Therefore the claims are also non-statutory subject matter.
Dependent claims 3-4 and 14-15 further limits the abstract idea by embellishing the abstract idea by describing an abstract process related to mathematical concepts by reciting determine 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 taking a corrective action associated with the route or the route schedule when the score is above the threshold and 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. Further embellishing that the invention is capable of including yet another abstract idea such as a mathematical concept does not integrate the abstract idea into a practical application or adds significantly more to the abstract idea. Therefore the claims are also non-statutory subject matter.
Dependent claims 5-7, and 16 further limits the abstract idea by embellishing the abstract idea and linking the judicial exception to a particular technological environment by introducing the limitation identify 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 and 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. Further embellishing that the invention is capable of displaying information in a generic computing environment does not integrate the abstract idea into a practical application or adds significantly more to the abstract idea. Therefore the claims are also non-statutory subject matter.
Dependent claims 8, 10 and 17 and further limits the abstract idea by embellishing the abstract idea and linking the judicial exception to a particular technological environment by introducing the limitation 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 and 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. Further embellishing the abstract idea by describing the data does not integrate the abstract idea into a practical application or adds significantly more to the abstract idea. Therefore the claims are also non-statutory subject matter.
Dependent claims 11 and 19 further limits the abstract idea by embellishing the abstract idea and linking the judicial exception to a particular technological environment by introducing the limitation 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; receive real-time information from vehicle devices, wherein a vehicle device is associated with each one of the plurality of vehicles; 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. The examiner views these additional elements as results-oriented steps given that there is no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result are currently present such that this is viewed as equivalent to “apply it” for merely implementing the abstract idea using generic computing components (See Id.). Therefore the claims are also non-statutory subject matter.
The ordered combination of elements in the dependent claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and the collective functions merely provide conventional computer implementation. Therefore, whether taken individually or as an order combination, the claims are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
For more information, see MPEP 2106.
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:
determine a plurality of routes and corresponding route schedules for a plurality of ride service requests ([068] and [0076] In block 410, a list of route stops is identified that is within a threshold distance of the location for the request to be completed. In some aspects, block 410 may be performed as described below with respect to FIG. 5. [0077] In block 420, a subset of route stops from the list identified in block 410 is identified. The subset includes route stops that are still pending for the current day. In other words, block 420 identifies stops that a vehicle 110 is yet to deliver to. Stops that have already been completed may not be particularly relevant to scheduling an on-demand transaction, since the vehicle 110 may have already departed the location of the completed stop and may no longer be in a proximity of that location for the remainder of the day.);
assign a plurality of vehicles to service each one of the plurality of routes ([0068] FIG. 3 shows exemplary table structures for relational databases of FIG. 2. The vehicle database 221 may include a vehicle identification 302, vehicle location 304, route identification 306, next stop identification 308, ratings 309, services 310, and association 311. The vehicle identification may serve to uniquely identify a vehicle 110 within the delivery system 100. The vehicle location column 304 may indicate a most recently reported location of the vehicle 110 identified by the vehicle ID column 302. The vehicle location column 304 may be set by the vehicle location management component 220 upon receiving a location update from a vehicle 110, such as any of vehicles 110a-b. [0069] The route identification field 306 may identify a delivery route assigned to the vehicle 110 identified via the vehicle ID field 302. Further see Fig.4 “460” and [080-084]);
for each one of the plurality of routes, assign a vehicle among the plurality of vehicles to a driver to perform a route according to a route schedule to which the vehicle is assigned ([0073] The operator database 241 includes an operator ID column 342, a route ID column 344, and a max deviation column 346. The operator ID column 342 contains a unique identifier for an operator of the vehicle. The route ID column 344 identifies a route in the route database 231 assigned to the operator identified by column 342. The maximum deviation column 346 indicates a maximum deviation from the route (identified by route ID 344) allowed for the operator (identified by operator id 342). );
monitor the plurality of vehicles, the plurality of routes and the corresponding route schedules ([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.);
detect an exception having a potential to impact the route schedule before the exception causes in 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 an potential to impact the route before the driver can accept the exception (i.e. new shipment).);
identify, a resolution to the exception wherein the resolution reduces or eliminates the potential to impact the route schedule ([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. ); and
proactively reduce or eliminate the potential to impact the route schedule by automatically implementing the resolution 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 using artificial intelligence and further teaches:
train an artificial intelligence engine associated with the server computer using historical data associated with one or more of the route schedule, the route, the vehicle, the driver, and past exceptions (([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. [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.);
detect, using the trained artificial intelligence engine an exception ([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. The input features used to train an ML model may include data about the status of a shipment based on information from the carrier tracking services. 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. [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).);
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 resolution to the exception includes taking a corrective action associated with the route or 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 resolution to the exception includes sending a warning to a device scheduling or monitoring the route 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 resolution 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 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.
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 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 ([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].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20230377466, Hernandez, REAL-TIME AIRCRAFT FLIGHT DELAY PREDICTION. [0016] Furthermore, airlines can obtain a benefit from this increase in robustness and accuracy of the flight delay information, especially in the turnaround phase of an aircraft when arriving at an airport. Further, such real-time flight delay information would allow an airline to take corrective actions ahead of a predicted disruption, thus reducing the impact of the disruption on a whole airline fleet flight schedule.
US 20230196265, Modica, SYSTEMS AND METHODS FOR PREDICTIVE IN-TRANSIT SHIPMENT DELIVERY EXCEPTION NOTIFICATION AND AUTOMATED RESOLUTION. The present disclosure relates generally to computer systems for shipping management. More particularly the present disclosure relates to online computer systems for predicting delivery exceptions and resolving delivery exceptions. More particularly, the present disclosure relates computer systems for multi-carrier shipping management with predictive exceptions and exception resolution.
US 11037055, Han, System For Dynamic Estimated Time Of Arrival Predictive Updates. The present disclosure relates to a system for facilitating a real-time, on-demand deliveries of perishable goods. In one example, the present disclosure relates to mechanisms and processes for tracking and determining the arrival status of a delivery.
K. Nishida and T. Nishi, "Dynamic Optimization of Conflict-Free Routing of Automated Guided Vehicles for Just-in-Time Delivery," in IEEE Transactions on Automation Science and Engineering, vol. 20, no. 3, pp. 2099-2114, July 2023
Yuanyuan Li, Claudia Archetti, Ivana Ljubić, Emerging optimization problems for distribution in same-day delivery, Computers & Operations Research, Volume 182, 2025,107105, ISSN 0305-0548.
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