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
Claims 1-20 were previously pending and subject to a non-final office action mailed 02/26/2026. Claims 1, 5, 7, 9, 13, 17, and 19-20 were amended; no claim was cancelled or added in a reply filed 06/25/2026. Therefore claims 1-20 are currently pending and subject to the final office action below.
Response to Arguments
Applicant's arguments filed 06/25/2026 in regards to section 101 rejection have been fully considered but they are not persuasive.
Applicant argues “The Office Action alleges, at Pages 2-3, that the claims fall within the "Methods of Organizing Human Activity" grouping of abstract ideas. Applicant respectfully disagrees. As stated in the August 4, 2025 USPTO memorandum (Kim, Charles. "Reminders on evaluating subject matter eligibility of claims under 35 U.S.C. 101." August 4, 2025), "Examiners should be careful to distinguish claims that recite an exception (which require further eligibility analysis) from claims that merely involve an exception (which are eligible and do not require further eligibility analysis)." (Emphasis added.) Applicant respectfully submits that, even if the current claim limitations were considered to involve an exception, these claim limitations do not recite any fundamental economic practices or other human-performed activity.
For example, amended Claim 1 recites a processor configured to "input the set of selected trip assignments including the trip information into the Al model configured to generate an optimal route for the set of selected trip assignments based upon the trip information including the respective trip type, wherein the Al model is trained using historical trip records including historical trip information associated with historical trips, the historical trip information including historical trip types of historical trips that were performed concurrently." These recitations do not fall within any of the enumerated categories of abstract ideas.” (remarks p. 8)
Applicant’s argument is not persuasive. The claim recite displaying trip assignments, receiving a user selection of trip assignments, organizing those selected assignments, and generating a route for concurrently performed trips. These limitations manage commercial delivery/transport activity and interactions between the user and trip assignment providers. Thus, the claims recite a certain method of organizing human activity, specially commercial interactions and business relations.
Moreover, the recited AI model receives assignment information and generates a route for completing selected trips. Under the broadest reasonable interpretation, this is the use of a computer model to organize and schedule transportation/delivery activity. The claim does not recite a specific AI architecture, particular training algorithm, feature engineering technique, data structure, or improvement to computer functionality. The AI limitation therefore implements the abstract logistics concept rather than changing the character of the claim into a technological improvement.
Applicant argues “One path to establishing a practical application is to show an improvement to another technology. See MPEP § 2106.04(d)(1). In this case, Claim 1 provides a technical improvement to machine learning by enabling a machine learning model to generate a route that facilitates multiple concurrent trips of different trip types, for example, factoring a compatibility of which types of trips can be performed at the same time. For example, the Al model may be capable of determining whether a rideshare trip and delivery can be performed concurrently based on various contextual factors and may generate a route based in part on this determination (e.g., whether to perform the different types of trips concurrently and/or in succession). This is accomplished by training an Al model using historical trip information associated with historical trips, the historical trip information including historical trip types of historical trips that were performed concurrently. Accordingly, in this case, "the specification sets forth an improvement in technology ... [and] the claim includes the components or steps of the invention that provide the improvement described in the specification," which is sufficient to establish a practical application. See MPEP § 2104.04(d)(1). Independent Claims 13 and 20, although differing in scope, include similar recitations.” (remarks p. 9).
Applicant argue sis not persuasive because the alleged improvement is stated as an improvement to the result of route generation, not an improvement to machine learning technology itself. The claim does not recite how the AI model is technically improved, how training is performed in a non-conventional way, or how computer operation is improved. Generating a better route for different trip types is an improvement to the underlying logistics/business process. It is not, as claimed, a technical improvement to the functioning of the computer or AI model.
Training or configuring an AI model using historical trip records merely specifies the informational content used by the model. The claim does not recite a particular training technique, model structure, or technological mechanism that improves computer performance. The limitation instead uses historical business/logistics data to improve the abstract task of selecting and routing trips.
Even assuming the specification describes benefits from using AI to generate routes, the claim must reflect a technological improvement. Here, the claim recites generic computing components, a user device application, and an AI model at a functional level. The claim does not recite the technical details that allegedly improve AI, computer operation, network performance, memory usage, or another technical field. Accordingly, the claim does not integrate the abstract idea into a practical application.
Applicant argues “In the instant Application, the pending claims clearly recite more than well-understood, routine, or conventional functionality computer systems, at least with respect to the at least one processor configured to "receive, from the user device, a selection of a set of trip assignments of the plurality of trip assignments, each of the set of selected trip assignments including trip information defining at least a respective trip type, the trip information including at least an origin and a destination," and "generate an optimal route for the set of selected trip assignments based upon an output of the AI model generated in response to an input of the selected trip assignments including the trip information defining the respective trip type to the AI model, wherein the AI model is trained using historical trip records including historical trip information associated with historical trips, the historical trip information including historical trip types of historical trips that were performed concurrently."
The Office Action provides no indication that these recitations of the pending claims (alone or as an ordered combination) are well understood, routine, or conventional in computer systems. As the Federal Circuit confirmed in Berkheimer, even if the Office Action asserts that the pending claims are rendered obvious by virtue of disparate publications, this does not amount to evidence that the recitations are well understood, routine, or conventional under this second step. See Berkheimer, 881 F.3d at 1369 ("Whether a particular technology is well-understood, routine, and conventional goes beyond what was simply known in the prior art” (remarks p. 10)
Applicant argument is not persuasive. The additional elements are generic computer components performing generic computer functions, including displaying information, receiving user input, processing data, generating an output, and displaying the output. These functions are recited at a high level of generality. The ordered combination likewise does not provide a non-generic arrangement of computer components or a technical improvement to computer functionality.
Applicant’s reliance on Berkheimer is acknowledged but is also not persuasive here. The rejection does not rely on establishing that the additional elements are well-understood, routine, conventional activity. Rather, the non-final office action rejected the additional elements as “apply it” limitations which do not require providing evidence under Berkheimer. Therefore, the additional elements were not characterized as well-understood, routine and conventional and no Berkheimer evidence was needed.
Applicant argues “The fact that the pending claims overcome the cited art for the reasons described below with respect to the traversal of the Section 103 rejection strengthens the conclusion that these steps are not well understood, routine, and conventional.” (remarks p. 11).
Applicant’s argument is not persuasive. Eligibility under 101 is separate from novelty and obviousness under section 102 and 103. Even assuming, arguendo, that the claims distinguish the cited prior art, that would not establish that the claims recite an inventive concept under step 2B. The relevant inquiry is whether the additional elements transform he abstract idea into a patent eligible application. For the reasons discussed above, they do not.
Applicant’s arguments with respect to 103 rejection have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 101
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 claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim 1/13/20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim recites “display a plurality of trip assignments, each of the plurality of trip assignments; receive a selection of a set of trip assignments of the plurality of trip assignments, each of the set of selected trip assignments including trip information defining at least a respective trip type, the trip information including at least an origin and a destination; generate an optimal route for the set of selected trip assignments based upon an output of the AI model generated in response to an input of the selected trip assignments including the trip information defining the respective trip type to the AI model; and display the generated optimal route for the set of selected trip assignments.”
The limitations above, as drafted, is a process that, under its broadest reasonable interpretation, covers generate an optimal route for a driver which is a method of organizing a human activity. That is, the method allows for the generation instructions for a person to follow which is a method of managing personal behavior or relationships or interactions (i.e. following rules or instructions).
This judicial exception is not integrated into a practical application. In particular, the claim recites “computing device including at least one processor in communication with at least one memory device”, “an application executing on the user device”, “user device” and “a trip assignment provider device of a plurality of trip assignment provider devices”, “wherein the AI model is trained using historical trip records including historical trip information associated with historical trips, the historical trip information including historical trip types of historical trips that were performed concurrently” (claim 1), “computing device including at least one processor in communication with at least one memory device”, “an application executing on the user device”, “user device” and “a trip assignment provider device of a plurality of trip assignment provider devices”, “wherein the AI model is trained using historical trip records including historical trip information associated with historical trips, the historical trip information including historical trip types of historical trips that were performed concurrently” (claim 13), “at least one non-transitory computer readable media”, “computing device including at least one processor in communication with at least one memory device”, “an application executing on the user device”, “user device” and “a trip assignment provider device of a plurality of trip assignment provider devices”, “wherein the AI model is trained using historical trip records including historical trip information associated with historical trips, , the historical trip information including historical trip types of historical trips that were performed concurrently “(claim 20). Each of the additional limitations is recited at a high level of generality and amounts to no more than mere instructions to apply the exception using a generic computer component. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements, alone or in combination, are nothing more than mere instructions to apply the exception on a general computer.
Dependent claims 2-12 and 13-19 also directed to an abstract idea without significantly more because they further narrow the abstract idea described in relation to claim 1 without successfully integrating the exception into a practical application or providing significantly more limitations.
Claim Rejections - 35 USC § 103
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 4, 6-8, 11-13, 16, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Daugherty (US 2023/0124968) in view of Williams (2024/0377211)
As per claim 1/13/20, Daugherty discloses a computing device
cause, using an application executing on the user device, the user device to display a plurality of trip assignments, each of the plurality of trip assignments associated with a trip assignment provider device of a plurality of trip assignment provider devices ([0020] An exemplary system 100 in which embodiments of the present systems and methods may be implemented is shown in FIG. 1. In this example, system 100 may include a plurality of sender systems 102A-M, driver systems 104A-N, server 106 and a communications network, such as Internet 108. Sender systems 102A-M typically include a mobile device, such as a smartphone or tablet, but may include any computing device capable of running software programs, and may include general purpose computing devices, such as a personal computer, laptop, smartphone, tablet computer, etc., and may include special-purpose computing devices, such as embedded processors, systems on a chip, etc., that may be included in standard or proprietary devices….[0021]… Driver app 104A-N may include functionality such as push notifications that may be sent to drivers announcing a potential shipment on which they may bid, an in app map of potential shipments on which drivers may bid, the shipment driver price—the price paid to the driver for delivering the individual shipment in question, driver offers—offers submitted by the driver to deliver the shipment as posted for the shipment driver price, etc. In many cases, delivery tasks may be consolidated into multi-delivery groups, known as consolidations. For example, several individual deliveries to the same building, block, general area, etc., may be grouped together to form a consolidation, and the delivery drivers then may submit offers to make all the deliveries in a consolidation. Individual deliveries may be consolidated, not just by close physical proximity, but also by overall efficiency…the sender systems are trip assignment provider devices because each sender system supplies a shipment requiring delivery. The driver’s app map and notifications display multiple available delivery assignments associated with those sender systems);
receive, from the user device, a selection of a set of trip assignments one or more of the plurality of trip assignments, each of the set of one or more selected trip assignments including trip information 214, driver capacity and route compatibility of the delivery offer is checked, for example, based on the pickup location, delivery location, delivery schedule, driver location, driver capacity, current driver assignments, etc. At 216, it may be determined whether the delivery offer is valid based on the checks performed at 214. ).
generate an optimal route for the set of selected trip assignments…in response to an input of the selected trip assignments including information about historical trips that were performed concurrently ([0006] In embodiments, the desirability score may be based on at least one of a time between a time a consolidation is made available and a time a delivery driver's offer is received, a distance to a first pickup location from a driver's location at a time a delivery driver's offer is received, an estimated drive distance for a consolidation, an estimated driving time for a consolidation, a driver's personal efficiency average, a creation time of a delivery task, a time a delivery task is made available, a deadline for performing a delivery task, a time a delivery driver's offer is received, a number of delivery drivers' offers on a consolidation, an age of a driver's account, a driver rating average, a number of past delivery drivers' offers made in a time period, a number of delivery tasks performed in a time period, and a number of the delivery driver's offers made in a time period since creation of a driver profile. ..[0008] The method may further comprise calculating a metric for a route using a driver's current location, a driver's existing commitments, a location of a new delivery, a sizing of a new delivery, and a deadline for a new delivery. The method may further comprise comparing the metric with the driver's existing commitments and determining whether the route is compatible with the driver's existing commitments…[0049] For example, process 224 may use a simple insertion heuristic to build two min-cost Hamiltonian routes. Those routes may be translated directly into ordered lists. One list may be based on first pickup locations (that is, the pickup location of the first delivery task in every consolidation), with the point-to-point cost being calculated using, for example, a Haversine distance. The second list may be based on current driver locations. Both orderings may be attached to the data input to a parallel matching process 226, for example, by adding an index value to every offer, according to the sort.)
However, Daugherty does not disclose but Williams discloses a user device configured to use an artificial intelligence (AI) model to generate routes associated with different trip types ([0006] The present embodiments may relate to, inter alia, systems and methods for improved transportation route generation using artificial intelligence. A system and method may use data collected by travelers to generate a model that may be used to generate the most efficient transportation routes. The generated route may include one or more route segments, each of which may be associated with a different type of transportation.);
generate an optimal route historical trips. The at least one processor may be further configured to generate a user interface. The user interface may include instructions associated with the generated route. The instructions may indicate the respective type of transportation to be used for each route segment… [0103] In the exemplary embodiment, computer-implemented method 500 may further include generating 506, based upon the trip request using an AI model, a route including a plurality of route segments. Each of the plurality of route segments may be associated with a respective type of transportation. The AI model may be trained using historical trip records including historical trip data associated with historical trips. In some embodiments, the historical trip data includes one or more of historical destinations, historical routes, historical types of transportation used, historical costs, user feedback, and/or historical events associated with historical trips. In some embodiments, generating 506 the route may be performed by server computing device 102, for example, by executing analytics module 332 (shown in FIG. 3)…..in the combination, Daugherty supplies the selected set of assignments and information for each selected assignment, while Williams supplies the model that receives that information and generates the optimized route. Daugherty also teaches consolidated and concurrently active assignments, multiple existing driver commitments, tack-on deliveries, and historical driver performance information. Williams teaches training the AI model using historical trip records including historical transportation types. Applying Williams training technique to the historical trip records generated by Daugherty’s concurrent assignment system results in training records containing the types of historical trips that were performed concurrently) and
cause, using the application executing on the user device to display the generated optimal route for the set
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitation above as taught by Williams in the teaching of Daugherty, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 4/16, Daugherty discloses wherein the at least one processor is further configured to receive the plurality of trip assignments from the plurality of trip assignment provider devices ([0020] An exemplary system 100 in which embodiments of the present systems and methods may be implemented is shown in FIG. 1. In this example, system 100 may include a plurality of sender systems 102A-M, driver systems 104A-N, server 106 and a communications network, such as Internet 108. Sender systems 102A-M typically include a mobile device, such as a smartphone or tablet, but may include any computing device capable of running software programs, and may include general purpose computing devices, such as a personal computer, laptop, smartphone, tablet computer, etc., and may include special-purpose computing devices, such as embedded processors, systems on a chip, etc., that may be included in standard or proprietary devices. Sender systems 102A-M may include a sender app 110A-M, which may perform the sender functions and method steps of embodiments of the present systems and methods, as described below. Typically, a sender is a user who needs a shipment sent from a pickup location to a delivery location and utilizes a sender system, such as 102A, and a sender app, such as 110A, in order to obtain such delivery services. Sender app 110A-M may include functionality such as the shipment sender price—the price paid by the sender to send the individual shipment in question, etc. [0021] Driver systems 104A-N typically include a mobile device, such as a smartphone or tablet, but may include any computing device capable of running software programs, and may include general purpose computing devices, such as a personal computer, laptop, smartphone, tablet computer, etc., and may include special-purpose computing devices, such as embedded processors, systems on a chip, etc., that may be included in standard or proprietary devices. Driver systems 104A-N may include a driver app 112A-N, which may perform the driver functions and method steps of embodiments of the present systems and methods, as described below. Typically, a driver is a user operating a vehicle who drives a delivery from a pickup location to a delivery location and utilizes a driver system, such as 104A, and a sender app, such as 112A, in order to obtain such delivery services. In embodiments, the present systems and methods may organize functionality in terms of a shipment having a single pickup location and a single delivery location. Driver app 104A-N may include functionality such as push notifications that may be sent to drivers announcing a potential shipment on which they may bid, an in app map of potential shipments on which drivers may bid, the shipment driver price—the price paid to the driver for delivering the individual shipment in question, driver offers—offers submitted by the driver to deliver the shipment as posted for the shipment driver price, etc. In many cases, delivery tasks may be consolidated into multi-delivery groups, known as consolidations. For example, several individual deliveries to the same building, block, general area, etc., may be grouped together to form a consolidation, and the delivery drivers then may submit offers to make all the deliveries in a consolidation. Individual deliveries may be consolidated, not just by close physical proximity, but also by overall efficiency. For instance, two items may require delivery and both delivery locations are remote, say 20 miles and 50 miles, respectively, from the pick-up location. However, if the 20-mile delivery is cheaply insertable (i.e. it is more efficient in, say, delivery time or mileage, compared with other options) into the 50-mile delivery, then these two tasks could be consolidated together, although they are not in close physical proximity. For simplicity, delivery tasks may be termed consolidations, regardless of whether the consolidation includes a plurality of delivery tasks or just one delivery task.)
As per claim 6/18, Daugherty does not disclose but Williams discloses wherein the at least one processor is further configured to train the Al model based upon the historical trip records ([0034] In the exemplary embodiment, the server computing device may be configured to generate an AI model, referred to herein as a route generating model, that may used to generate routes based upon input data….[0036] The server computing device may be configured to generate the route generating model by analyzing historical trip records including historical trip data (e.g., historical destinations, routes, types of transportation used, telematics data, costs, user feedback, and/or events such as collisions and/or injuries occurring during the trip) associated with historical trips. The server computing device may be configured to perform a statistical analysis of the historical trip records to generate the structure assessment model)(please see claim 1 rejection for combination rationale).
As per claim 7/19, Daugherty discloses wherein the optimal route includes each origin and each destination associated with of the one or more selected trip assignments ([0021]… In many cases, delivery tasks may be consolidated into multi-delivery groups, known as consolidations. For example, several individual deliveries to the same building, block, general area, etc., may be grouped together to form a consolidation, and the delivery drivers then may submit offers to make all the deliveries in a consolidation. Individual deliveries may be consolidated, not just by close physical proximity, but also by overall efficiency. For instance, two items may require delivery and both delivery locations are remote, say 20 miles and 50 miles, respectively, from the pick-up location. However, if the 20-mile delivery is cheaply insertable (i.e. it is more efficient in, say, delivery time or mileage, compared with other options) into the 50-mile delivery, then these two tasks could be consolidated together, although they are not in close physical proximity. For simplicity, delivery tasks may be termed consolidations, regardless of whether the consolidation includes a plurality of delivery tasks or just one delivery task…[0025]… If a delivery offer is valid, then at 214, driver capacity and route compatibility of the delivery offer is checked, for example, based on the pickup location, delivery location, delivery schedule, driver location, driver capacity, current driver assignments, etc…[0026]… scoring process may include, for example: [0027] Time to offer as time between the consolidation's publication time (e.g. 11:30 AM) and driver's time of offer (e.g. 11:33 AM) [0028] Calculated distance to first pickup location from driver's location at time of offer based on haversine distance. [0029] Estimated drive distance for the consolidation based on turn-by-turn driving directions from Google Maps API. [0030] Estimated driving time for the consolidation based on turn-by-turn driving directions from Google Maps API. [0031] Driver's personal efficiency average [0032] Delivery task creation time, publication time, and deadline (e.g. 10:45 AM, 11:30 AM, 5:00 PM) [0033] Offer creation time (e.g. 11:33 AM) [0034] Number of offers on the consolidation [0035])
As per claim 8, Daughtery does not disclose but Williams discloses wherein the at least one processor is further configured to receive telematics data generated by the user device executing the application while the user is traveling the optimal route (0110] In some embodiments, computer-implemented method 500 may further include receiving 524, from the user device during the trip, telematics data. In some such embodiments, the telematics data may be generated by at least one sensor of the user device. Additionally or alternatively, in some such embodiments, the user device may be configured to communicatively pair with a transportation device, and the telematics data may be generated by at least one sensor of the transportation device. In some embodiments, receiving 524 the telematics data may be performed by server computing device 102, for example, by executing communication module 330 (shown in FIG. 3).)(please see claim 1 rejection for combination rationale).
As per claim 11, Daughtery does not disclose but Williams discloses wherein the at least one processor is further configured to: compute a cost or score based upon the received telematics data; and cause, using the application, the user device to display the computed cost or score ([0026]… Such telematics data, along with historical data relating to events (e.g., accidents) occurring during the trips, may be used to train the AI model, for example, to determine a safety and/or generate a risk or loss score (e.g., associated with a likelihood of an injury or financial loss occurring) for a given route. The risk or loss score may by displayed by the mobile app, and may be updated in real time based on telematics data collected during a trip. In some embodiments, the risk score may be used to determine an insurance cost for a trip and/or to generate routes that prioritize safety of the user.)(please see claim 1 rejection for combination rationale).
As per claim 12, Daugherty does not discloses wherein the at least one processor is further configured to: determine a current location of the user device based upon the telematics data; and cause, using the application, the user device to display at least one instruction determined based upon the current location of the user device ([0028] In the exemplary embodiment, the server computing device may receive an origin and destination for a requested trip. For example, the server computing device may cause a mobile app executing on the user device to prompt a user to input a desired destination. The server computing device may further cause the mobile app to prompt the user to input an origin for the trip, or may determine the origin of the trip based on the user's current location (e.g., by using GPS to determine a current geolocation of the user device)…[0046]…Timing of when the mobile app displays the information may be determined based upon a current location of the user)(please see claim 1 rejection for combination rationale).
Claim(s) 2-3, 5, 9-10, 14-15 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Daugherty (US 2023/0124968) in view of Williams (2024/0377211), as disclosed in the rejection of claim 1/8, in further view of Leoni (US 2018/0046964).
As per claim 2/14, Daugherty does not disclose but Leoni discloses wherein the at least one processor is further configured to: retrieve driver information corresponding to the user ([0042] Among other functions, the platform allows stakeholders to create/update a personal profile, create/update a company profile, create/update a loading site profile, upload license or certification information, create load delivery requests, assign load delivery requests, accept load delivery requests, track status events associated with a load delivery, upload relevant load delivery information, and manage communications with other stakeholders., [0077] Referring to FIG. 5, exemplary profile databases are shown. The central data store 510 may comprise a personal profiles database 512, a company profiles database 513, and a site profiles database 514. Profile data can include personal profile data, company profile data, and site profile data.); and select the plurality of trip assignments to display based upon the driver information ([0082] Staffing analysis 416 allows the application to match a driver (or other vehicle/equipment operator) with a particular set of certifications to a job according to the staffing and compliance needs of the job's load delivery, or according to the relative decrease in liability risk that the job is purported to incur based on the driver's past history through the platform.).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitation above as taught by Leoni in the teaching of Daugherty, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 3/15, Daugherty does not disclose but Leoni discloses wherein the driver information indicates trip assignment provider devices with which the user has registered ([0078] Personal profile data comprise user information, including at least the name and the role of the user and any licensing and certification information for the user. Company profile data comprise company information, including at least the name, address, and phone number of the company. Site profile data comprise loading site info, including location, policies/procedures, delivery hours, and available equipment for use by drivers. Though all users would have a personal profile, not all users may be associated with a company profile. Certain roles, such as carriers, dispatchers, receivers, shippers, and brokers would be associated with a company profile and with the exception of most brokers, would typically also be associated with at least one site profile.)(please see claim 2 rejection for combination rationale).
As per claim 5/17, Daugherty does not disclose but Leoni discloses wherein the at least one processor is further configured to transmit an acceptance message to trip assignment provider devices of the plurality of trip assignment provider devices that are associated with the set of selected trip assignments ([0127] The job creator may be notified when the job is accepted by a driver. In one embodiment, the job creator may manually provide the driver authorization to proceed with the load delivery through the application)(please see claim 2 rejection for combination rationale).
As per claim 9, Daugherty does not disclose but Leoni discloses wherein the at least one processor is further configured to determine a first trip assignment of the one or more selected trip assignments has been completed based upon the telematics data ([0131] In another embodiment, the application may be configured to periodically detect the location of the client device of the driver. As the active load progress through delivery, updates may be automatically generated based on the location of the driver (and presumably also the driver's vehicle and the load being delivered). For example, if the application detects that the driver's client device is approaching the origin site of Job A, the application may automatically update the current status 1304 of Job A to ‘Origin Site Reached.’ Subsequently, if the application detects that the driver's client device is leaving the origin site, the application may automatically update the current status 1304 to ‘Pick Up Confirmed.’).
Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to include the limitation above as taught by Leoni in the teaching of Daugherty, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
As per claim 10, Daugherty does not disclose but Leoni discloses wherein the at least one processor is further configured to transmit a completion message indicating the first trip assignment has been completed to the trip assignment provider devices associated with the first trip assignment ([0132] As shown in FIG. 13A, the active load deliveries screen 1300 comprises another active load 1312 titled ‘Job C’ that is at a separate stage of the load delivery process. As shown, the current status 1314 of Job C may be ‘Confirmed Delivery,’ and the job details 1316 may display that the route is complete (i.e., the driver has reached the destination site). The driver assigned to Job C may select a ‘Upload Bill of Lading’ button 1318, thus completing the load delivery process as described in FIG. 8B.. [0157] Referring to FIG. 14D, the dashboard 1400 is shown illustrating an exemplary notification card for the final stages of a load delivery. Upon reaching a destination site and confirming delivery, the driver may complete the load delivery process through the application by uploading a signed Bill of Lading. Once uploaded, the dashboard 1400 may display a notification card 1448 to all stakeholders showing a preview 1449 of the Bill of Lading and a facility for a stakeholder to leave feedback 1450 for the driver. [0079] Referring back to FIG. 4, load management 412 allows stakeholders to schedule a load delivery, assign the delivery to available drivers, view and update active loads, and access a dashboard that functions as a notifications feed for all active loads associated with the stakeholder. Load management also allows the various stakeholders of a pending load to send, upload and access up-to-date information regarding the load delivery, such as current location, text/image updates from stakeholders, weather conditions, delivery status (e.g., on route, delayed, awaiting signature, etc.), feedback/ratings/reviews, documents (such as Bills of Lading), and other relevant information.”)(please see claim 9 rejection for combination rationale).
Pertinent Art:
Woodard (US 2016/0202074) Predicting and Utilizing variability of travel times in mapping services.
Aman (US 2021/0073734) Methods and system of route optimization for load transport.
Conclusion
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 OMAR ZEROUAL whose telephone number is (571)272-7255. The examiner can normally be reached Flex schedule.
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, Lynda Jasmin can be reached at (571) 272-6782. 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.
OMAR . ZEROUAL
Examiner
Art Unit 3628
/OMAR ZEROUAL/Primary Examiner, Art Unit 3629
Prosecution Insights