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, 15, 16, 18, and 19 are amended. Claims 4, 9, 12, and 13 are canceled. Claims 1-3, 5-8, 10, 11, and 14-20 are pending.
Response to Arguments
Applicant's arguments filed 07/28/2025 regarding the 35 U.S.C. 101 rejection have been fully considered but they are not persuasive.
Under Step 2A Prong One, Applicant argues that Independent claim 1 is not directed to certain methods of organizing human activity or mental processes. Examiner disagrees. The certain methods or organizing human activity is used to describe concepts relating to: commercial or legal interactions and managing personal behavior or relationships or interactions between people (MPEP §2106.04(a)(2)). The MPEP further states that the sub-groupings encompass both activity of a single person and activity that involves multiple people (such as a commercial interaction), and thus, certain activity between a person and a computer may fall within the "certain methods of organizing human activity" grouping. Applicant’s claim 1 recite limitations that are drawn to delivery optimization for delivery companies, and corresponds to certain methods of organizing human activity (managing personal behavior or interactions, commercial interactions), as evidenced by limitations detailing receiving a list of tasks to be performed (by a delivery company driver), receiving constraint data associated with the tasks, generating an optimized delivery route based on the constraint data, and transmitting navigation instructions to a user. The claim also recite limitations that corresponds to mental processes (observation, evaluation, judgment, opinion), as evidenced by limitations detailing analyzed constraint conditions and location information to determine whether the location constraint is relevant to the task, and generating an optimized delivery route based on the delivery constraint data location data. The claims recite an abstract idea. Applicant argues that that their claims are not directed to “agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations” nor “social activities, teaching, and following rules or instructions”. Applicant’s argument is invalid. MPEP states that commercial interactions includes agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations and that managing personal behavior or relationships or interactions between people includes social activities, teaching, and following rules or instructions. The MPEP providing that that the sub-grouping includes these activities does not equate to the subgrouping being limited to these activities. The MPEP is merely providing an example of activities included under the sub-grouping. The examples are not exhaustive, and once again, the MPEP makes it clear that the certain methods or organizing human activity is used to describe concepts relating to: commercial or legal interactions and managing personal behavior or relationships or interactions between people. The claim limitations reciting limitations detailing receiving a list of tasks to be performed (by a delivery company driver; see applicant’s specification [0044], [0045] for example), receiving constraint data associated with the tasks, generating an optimized delivery route based on the constraint data, and transmitting navigation instructions to a vehicles associated with the delivery company directly corresponds to certain methods of organizing human activity, specifically commercial interactions (business relations), following rules or instructions, and managing personal interactions, behavior, and relationships.
Regarding mental processes, Applicant argues that the claims, as amended, cannot be reasonably performed in the human mind, specifically “…steps include using a API to receive information from third-party systems, using map and delivery constraint data to calculate an optimal delivery route for the third-party system, sending the optimized delivery route sending the data to display at a computerized systems, resulting in limitations that cannot be performed in the human mind, even with the aid of pencil and paper”. Examiner disagrees. MPEP §2106.04(a)(2)(III) states that claims can recite a mental process even if they are claimed as being performed on a computer. If the claimed invention is described as a concept that is performed in the human mind and applicant is merely claiming that concept performed 1) on a generic computer, or 2) in a computer environment, or 3) is merely using a computer as a tool to perform the concept, the claim is considered to recite a mental process. In the Applicant’s claims, the limitations that correspond to mental processes (observation, evaluation, judgment, opinion) include limitations detailing analyzed constraint conditions and location information to determine whether the location constraint is relevant to the task, and generating an optimized delivery route based on the delivery constraint data location data. The claim limitations can be performed mentally, and are merely being performed via a computer. The claims recite a mental process.
Applicant argues under Step 2A Prong Two, Applicant argues that their claims are directed to an improvement in computer technology, and that their claims are similar to that of McRO, Inc. dba Planet Blue v. Bandai Namco Games American Inc., 120 USPQ2d 1091 (Fed. Cir. 2016) ("McRO"). Examiner disagrees. The judicial exception is not integrated into a practical application simply because the claims recite the additional elements of: a computing device, an application programming interface, one or more processors (claim 1 and 18), a third-party system, a computer-readable memory (claim 18), a non-transitory computer-readable medium (claim 19), and a plurality of vehicles associated with a delivery company used to perform the delivery tasks. The additional elements are computer components recited at a high-level of generality performing the above-mentioned limitations. The combination of the additional elements are no more than mere instructions to apply the judicial exception using a generic computer. Accordingly, in combination, 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 claims are directed to an abstract idea. There is no evidence of an improvement to computers, instead, the Applicant is merely using a computer to implement the limitations that correspond to the judicial exception(s). It is important to keep in mind that an improvement in the judicial exception itself (e.g., a recited fundamental economic concept) is not an improvement in technology. For example, in Trading Technologies Int’l v. IBG LLC, the court determined that the claim simply provided a trader with more information to facilitate market trades, which improved the business process of market trading but did not improve computers or technology. Similarly, the Applicant’s claim recitations are an improvement in the judicial exception, not an improvement in technology. Applicant’s argument of providing a practical implementation of delivery route optimization service system for organizations that are not able to effectively optimize their own delivery routes because these organizations may not have access to enough data (e.g., including location characteristic information) to identify all potential constraints for certain tasks and determine whether those constraints are relevant to the tasks is not an improvement in computer technology, but at best, indicates an improvement in the business process or judicial exception itself. Additionally, Applicant’s claims are no way similar to that of McRO. McRO is directed to an improvement “providing an integrated method embodied in computer software…for the rapid, efficient lip synchronization and manipulation of character facial expressions[.]” Id. The invention utilizes “a plurality of morph weight set transition rules” for “determining when to set keyframes[,] and setting those keyframes…taking into consideration the differences in mouth positions for similar phonemes based on context.” Id. at *9. For example, where an animator previously would have had to subjectively identify a problem with an animated face saying “hello” after silence, and insert a keyframe for the appropriate time in which the model would start to open its mouth, the invention uses rules to automatically set that appropriate keyframe." The McRO specifications describe that in the relevant art, applying the appropriate data points for basic sound phonemes, e.g. ‘aah,’ ‘ee,’ or ‘oo,’ was usually done using a “keyframe” approach. McRO, 2016 U.S. App. LEXIS 16703 at *7. In a keyframe approach, an animator sets the morph weights at certain important times, between which a computer program “interpolates” (filling in the data points between those morph weights). Id. at *8. The patents state that this method requires the animator to manually set a tediously high number of keyframes, which is time consuming, and can be inaccurate. Id. Applicant’s claims are in no way analogous to McRo. The basis for the court’s decision was that the claims improved a computer-related technology by enabling the computer to perform functions that previously could not be performed by a computer and that required the subjective judgement of a human. The court emphasized both the specific claiming of the rules and the specification’s explanation of how the claimed rules enabled the automation of these specific animation tasks that previously could not be automated. This enabling of functionality that could not previously be performed by a computer was what amounted to the improvement in computer-related technology, not the simple recitation of a set of particular rules. Examiner notes that the claim limitations detail receiving a list of tasks to be performed (by a delivery company driver), receiving constraint data associated with the tasks, generating an optimized delivery route based on the constraint data, transmitting navigation instructions to a user, analyzing constraint conditions and location information to determine whether the location constraint is relevant to the task, and generating an optimized delivery route based on the delivery constraint data location data. As such, the claims at hand are not analogous to a computer-related technology that enables new functions that a computer could not have previously performed. Therefore, the Applicant’s claims are still patent ineligible for reasons set forth above.
The 35 U.S.C. 101 rejection is maintained.
Applicant’s arguments with respect to 35 U.S.C. 103 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 § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 16 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 16 recites the amended limitation “selecting, by the computing device, the plurality of optimized route based on the route scores associated with each candidate route”. There is insufficient support for this amended claim limitation in the specification. Applicant’s specification discloses that the delivery route optimization system can generate an optimized route for performing the list of tasks. To do so, the delivery route optimization system can generate a plurality of candidate routes. A score can be generated for each route, representing the cost of the route. For example, a cost of a route can be based on the distance traveled, the amount of time, the fuel expenditure, and the number/amount of constraints associated with the route. The delivery route optimization system can select the candidate route with the lowest cost as the optimized route for performing the list of tasks (see [0032] of the specification). The specification does not disclose that a plurality of optimized routes are selected based on route scores associated with each candidate route, but instead indicates that the most optimal route is selected (as in a single route). This is further disclosed in [0058], [0075]-[0076], [0085]-[0086], [0092], and [0101] of the specification as well.
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-3, 5-8, 10, 11, and 14-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e. an abstract idea) without significantly more.
Claims 1-3, 5-8, 10, 11, and 14-17 recite a method (i.e. process), claim 18 recites a device (i.e. machine), and claims 19 and 20 recite a non-transitory computer-readable medium (i.e. machine or article of manufacture). Therefore claims 1-3, 5-8, 10, 11, and 14-20 fall within one of the four statutory categories of invention.
Independent claim 1, 18, and 19 recites the limitations of receiving a list of tasks to be performed from [a third-party system] associated with a delivery company via [an application programming interface] available to [third-party systems], wherein a respective task in the list of tasks includes a location associated with the performance of the respective task and the list of tasks are to be performed by [a plurality of vehicles] associated with the delivery company; receiving delivery constraint data describing constraints associated with one or more tasks in the list of tasks, wherein the delivery constraint data is received from the delivery company; accessing location constraint data describing constraints associated with one or more locations of one or more tasks in the list of tasks, wherein location constraint data includes one or more location constraints or time-based constraints determined based on stored map data of one or more locations associated with the list of tasks; for a respective task in the list of tasks: determining, based at least in part on a location associated with the respective task, one or more location constraints associated with the location; and determining, for a respective location constraint from the one or more location constraints, whether the respective location constraint is relevant to the respective task in the list of tasks based, at least in part, on the delivery constraint data; generating a plurality of optimized delivery routes based on the delivery constraint data and a list of relevant location constraints, the plurality of optimized delivery routes including a plurality of navigation instructions; and transmitting the plurality of navigation instructions to [a plurality of vehicles] associated with the delivery company. The claims recite limitations that are drawn to delivery optimization for delivery companies, and corresponds to certain methods of organizing human activity (managing personal behavior or interactions; commercial interactions, business relations), as evidenced by limitations detailing receiving a list of tasks to be performed (by a delivery company driver), receiving constraint data associated with the tasks, generating an optimized delivery route based on the constraint data, and transmitting navigation instructions to the vehicle associated with the delivery company. The claim also recite limitations that corresponds to mental processes (observation, evaluation, judgment, opinion), as evidenced by limitations detailing analyzing constraint conditions and location information to determine whether the location constraint is relevant to the task, and generating an optimized delivery route based on the delivery constraint data list of relevant location constraints. The claims recite an abstract idea.
Note: The features or elements in brackets in the above section are inserted for reading clarity, but are analyzed as “additional element” under Step 2A Prong Two and Step 2B, below.
The judicial exception is not integrated into a practical application simply because the claims recite the additional elements of: a computing device, one or more processors (claim 1 and 18), an application programming interface, a third-party system, a computer-readable memory (claim 18), a non-transitory computer-readable medium (claim 19), and a plurality of vehicles. The additional elements of a computing device, one or more processors (claim 1 and 18), an application programming interface, a third-party system, a computer-readable memory (claim 18), a non-transitory computer-readable medium (claim 19) are computer components recited at a high-level of generality performing the above-mentioned limitations. The combination of the additional elements are no more than mere instructions to apply the judicial exception using a generic computer. Further, the plurality of vehicles used to perform the delivery/delivery tasks amount to generally linking the judicial exception to a particular field of use. Accordingly, in combination, 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 claims are directed to an abstract idea.
The claims do 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 amount to no more than mere instructions to apply the exception using a generic computer, and generally linking the judicial exception to a particular field of use. Mere instructions to apply an exception using a generic computer cannot provide an inventive concept. Thus, when viewed as an ordered combination, nothing in the claims add significantly more (i.e. an inventive concept) to the abstract idea. The claims are not patent eligible.
Dependent claims 2, 3, 5-8, 10, 11, 14-17, and 20 recite additional limitations that are further directed to the abstract idea analyzed in the rejected claims above. The claims also recite additional elements that have been analyzed in the rejected claims above. Thus, claims 2, 3, 5-8, 10, 11, 14-17, and 20 are also rejected under 35 U.S.C. 101.
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-3, 5-8, 10, 11, 15-17, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Laury (2019/0228375) in view of Goldman (2019/0317526) further in view of Panzica (2020/0233415).
Claim 1: Laury discloses: A computer-implemented method, the method comprising:
for a respective task in the list of tasks: determining, based at least in part on a location associated with the respective task, one or more location constraints associated with the location; and (Laury ¶0025 disclosing determining the delivery regions by calculating boundaries for the delivery region; ¶0029 disclosing determining one or more delivery locations (location associated with task) based on the recipient location (location constraint), each location representing where the delivery recipient can access the autonomous delivery vehicle and the requested payload (delivery tasks); delivery management system can determine each of the delivery locations as one of the stop locations (e.g., a predetermined geographical location where a vehicle can stop without interrupting the flow of traffic, where a person can approach and access the vehicle, such as a shoulder, a drive way, a parking lot or spot, etc.) closest to the recipient location (all location constraints associated with the location); see also ¶0027 disclosing the delivery vehicle approaches the delivery locations, such as when the delivery vehicle is within a threshold distance/range from the delivery locations or when the vehicle passes a specified location, the delivery vehicle can autonomously determine a stopping location based on real-time information (e.g., sensor information) representing a current situation/condition surrounding the vehicle, on the road, traffic condition, etc.)
determining, for a respective location constraint from the one or more location constraints, whether the respective location constraint is relevant to the respective task in the list of tasks based, at least in part, on the delivery constraint data; (Laury ¶0026 disclosing the delivery regions including resting locations which correspond to geographic locations and/or facilities designated for refueling the autonomous delivery vehicles (by, e.g., refilling gasoline or recharging electrical batteries) and/or designated for storing or parking the autonomous delivery vehicles between delivery missions (delivery constraint data); note that the pickup locations (which may be in included in the delivery region/boundaries can include geographic locations and/or facilities where products or items can be accessed (delivery task); ¶0029 disclosing based on the recipient location (delivery constraint), the delivery management system can determine one or more delivery locations, each location representing where the delivery recipient can access the autonomous delivery vehicle and the requested payload (delivery task); delivery management system can determine each of the delivery locations as one of the stop locations (e.g., a predetermined geographical location where a vehicle can stop without interrupting the flow of traffic, where a person can approach and access the vehicle, such as a shoulder, a drive way, a parking lot or spot, etc.) closest to the recipient location(thus the location constraint is relative to the task of accessing the vehicle and payload at the delivery/recipient location (delivery constraint); delivery management system can determine each the delivery locations as a location designated by the corresponding delivery recipient (e.g., a preferred location pre-identified by the delivery recipient or identified at the time of the order/request; see also ¶0034 disclosing delivery management system calculating a route associated with traversing from the starting point to the destination point (task), the route being calculated also minimizes or maximizes a cost, a condition, or a resource (e.g., a distance, travel time, fuel/electrical charge, travel speed, etc.) (delivery constraints); the system considers real-time road conditions, in calculating the delivery route; system can consider real-time conditions that include current or historical traffic conditions (e.g., traffic flow, reported accidents on the same road and/or within a threshold distance from one or more points on a potential route), weather conditions, black-out areas (e.g., construction zones or intersections with high rate of traffic accidents) (thus the location constraints are relevant to the respective task (traversing the route from the starting point to the destination point in delivering the order, and is based at least in part on delivery constraints such as minimizing or maximizing fuel/electrical charge, cost, etc.; see also ¶0066 that discloses an example of the delivery management system using locations that correspond to the location of the task; determining whether a resting location or stop location along the delivery route is relevant to fueling or charging a vehicle and based ; maneuver detail can be used for pulling up to a specific loading zone at the corresponding pickup location, for positioning the vehicle at a charging location or a fuel pump at the corresponding resting location, for maneuvering into a specific parking lot or a private driveway, etc.; user-provided permission to access private property and/or coordinates of the permitted location which can also be used to determine a stop location, such as be considering the permitted location first before searching for other potential stop locations, and autonomously determine and perform maneuvers for stopping at the determined location)
generating, by the computing device, a plurality of optimized delivery routes based on the delivery constraint data and a list of relevant location constraints, the plurality of optimized delivery routes including a plurality of navigation instructions; and (Laury ¶0018 disclosing the delivery management system can allocate/move the autonomous delivery vehicles to specific geographic regions (by, e.g., controlling geographic locations of the autonomous delivery vehicles), generate delivery routes including one or more pickup locations and one or more delivery locations (e.g., locations corresponding to one or more intended recipients), control the autonomous delivery vehicles to traverse the delivery routes, coordinate loading processes at the pickup location; ¶0021 disclosing the delivery management system can generate the delivery route, assign/move one of the autonomous delivery vehicles, combine the delivery missions, or a combination thereof based on an optimization mechanism (e.g., a mechanism for optimizing a delivery time, a travel distance, etc.); ¶0034 disclosing the delivery management system can use the one or more mechanisms to calculate the route that minimizes or maximizes a cost, a condition, or a resource (e.g., a distance, travel time, fuel/electrical charge, travel speed, etc.) associated with traversing from the starting point to the destination point, and also consider real-time road conditions, in calculating the delivery route, e.g., the use the route calculation mechanism to generate a set of potential routes that go from the starting point to the destination point; ¶0040 disclosing delivery management system can group multiple delivery missions on one delivery route for picking up items from multiple locations, delivering to multiple locations, or a combination thereof (e.g., including one or more pickup locations and/or including one or more delivery locations); delivery management system can group the delivery missions using the optimization mechanism that uses a variety of factors as input parameters, e.g., vehicle current locations, remaining amount of fuel or the available travel range/distance of the vehicles, the time-requirements of remaining delivery missions, a delivery time of one or more vehicles, a travel distance for one or more vehicles, etc.; ¶0076 the system can group and/or sequence the missions/tasks using the optimization mechanism; optimization mechanism can further calculate routes that correspond to the combinations/groupings/sequences of the tasks and characteristics/traits associated with the routes; ¶0079 disclosing the optimizing mechanism also calculating a first route including a first target zone where the autonomous delivery vehicle is allowed to stop such that the delivery recipient can access/pick up the requested payload; ¶0080 further discloses the optimized mechanism can use a travel status (e.g., the vehicle current location, traffic conditions, etc. to calculate a first stop location based on real-time information (e.g., vehicle sensor information, traffic information, road conditions, recipient location, etc.) associated with the environment surrounding the vehicle; see also ¶0081; ¶0068 disclosing the delivery management system can communicate the vehicle trip detail, the delivery mission, and the delivery route to the selected vehicle (e.g., the autonomous delivery vehicle))
transmitting, by the computing device, the plurality of navigation instructions to a plurality of vehicles associated with the delivery company. (Laury ¶0018 disclosing the delivery management system can allocate/move the autonomous delivery vehicles to specific geographic regions (by, e.g., controlling geographic locations of the autonomous delivery vehicles), generate delivery routes including one or more pickup locations and one or more delivery locations (e.g., locations corresponding to one or more intended recipients), control the autonomous delivery vehicles to traverse the delivery routes, coordinate loading processes at the pickup locations; ¶0068 disclosing the delivery management system can communicate the vehicle trip detail, the delivery mission, and the delivery route to the selected vehicle (e.g., the autonomous delivery vehicle); ¶0124 disclosing aspects of the system may be practiced on one or more devices (e.g., computing devices) operated by end-users, operated autonomously, operated by a teleoperation center, operated by third parties (e.g., entities or services assisting or performing the dynamic driving task))
Laury in view of Goldman discloses:
receiving, by a computing device with one or more processors, a list of tasks to be performed from a third-party system associated with a delivery company via an application programming interface available to third-party systems, wherein a respective task in the list of tasks includes a location associated with the performance of the respective task and the list of tasks are to be performed by a plurality of vehicles associated with the delivery company;
Laury discloses that a list of tasks to be performed from a third-party system, wherein a respective task in the list of tasks includes a location associated with the performance of the respective task and the list of tasks are to be performed by a plurality of vehicles (Laury ¶0019 disclosing the delivery management system generating a delivery mission for each order, the delivery mission incusing tasks for the pickup of the items from locations and providing secured access; ¶0033 disclosing the delivery management system can determine a list of delivery tasks (e.g., a pickup task or a drop off task for a delivery mission); ¶0012 disclosing the merchant performing loading operations, and ¶0064 disclosing the user performing delivery retrieval tasks; ¶0124 disclosing the delivery management system that can include delivery vehicles operated by third parties (e.g., entities or services assisting or performing the dynamic driving task); ¶0030-¶0033 disclosing delivery tasks performances for the missions associated with the locations, e.g., stopping at a determined stop location to allow a delivery recipient to access the payload (¶0031); ¶0055 disclosing the tasks can include instructions for picking up ( e.g., loading or providing loading access) and/or dropping off (e.g., unloading or providing retrieval access) items, traveling to associated locations (e.g., loading/unloading locations), functions to be performed at the associated locations, etc.); the delivery mission being one or more tasks or a sequence of tasks associated with a common item and/or a common location; ¶0014 discloses the invention implemented via a computer). Although strongly suggested since the reference is directed to the delivery of items and a delivery management system performing various tasks, Laury does not explicitly disclose receiving, by a computing device with one or more processors, a list of tasks to be performed from a third-party system associated with a delivery company via an application programming interface available to third-party systems, wherein a respective task in the list of tasks includes a location associated with the performance of the respective task and the list of tasks are to be performed by a plurality of vehicles associated with the delivery company. Goldman suggests or discloses this limitation/concept: (Goldman ¶0057 the autonomous vehicle can broadcast its availability to the service entities; the autonomous vehicle can be addressing a current task associated with the autonomous vehicle, the current task can include addressing a selected vehicle service assignment (e.g., transporting a user), receiving maintenance, receiving fuel, charging an electric power source of the autonomous vehicle, etc.; ¶0058 the computing system can determine that the autonomous vehicle is to become available to perform one or more vehicle services (at a later time) based at least in part on the data associated with the status of the autonomous vehicle; the vehicle computing system can determine that the autonomous vehicle will soon arrive at a destination location for a current transportation service assignment, or that the vehicle maintenance, re-fueling, re-charging, etc. will be completed shortly; ¶0031 disclosing an autonomous vehicle can be associated with a third party; the third party can include, for example, an owner, a manufacturer, a vendor, a manager, a coordinator, a handler, etc. of the autonomous vehicle; the third party can be an individual, a group of individuals, an entity, a service entity, a group of entities, etc.; ¶0032 disclosing the autonomous vehicle can perform vehicle services for a plurality of different service entities; a service entity can be associated with the provision of one or more vehicle services, e.g., a service entity can be an individual, a group of individuals, a company, a group of companies (e.g., affiliated entities), and/or another type of entity that offers and/or coordinates the performance of one or more vehicle services to one or more users; ¶0066; ¶0034, ¶0035, ¶0092 various discloses the communication between the service entities and vehicles via API). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Laury to include receiving, by a computing device with one or more processors, a list of tasks to be performed from a third-party system associated with a delivery company via an application programming interface available to third-party systems, wherein a respective task in the list of tasks includes a location associated with the performance of the respective task and the list of tasks are to be performed by a plurality of vehicles associated with the delivery company as taught by Goldman. One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to modify Laury in in order to provide an AV with the flexibility to perform vehicle services for a plurality of service entities in an efficient manner (see ¶0029 of Goldman).
receiving, by the computing device, delivery constraint data describing constraints associated with one or more tasks in the list of tasks, wherein the delivery constraint data is received from the delivery company;
Laury discloses delivery constraint data describing constraints associated with one or more tasks in the list of tasks, but does not explicitly disclose receiving, by the computing device, delivery constraint data describing constraints associated with one or more tasks in the list of tasks, wherein the delivery constraint data is received from the delivery company. Goldman suggests or discloses this limitation/concept: (Goldman ¶0059 the vehicle computing system can indicate to a plurality of service entities that the autonomous vehicle is to become available (at the later time) to perform one or more vehicle services; the vehicle computing system can go online with (e.g., establish a plurality of communication sessions with, provide communications to, etc.) the plurality of service entities to indicate the vehicle's upcoming availability; the vehicle computing system can provide a time (e.g., estimated time, estimated amount of time, etc.) when the autonomous vehicle will become available and/or able to accept a vehicle service assignment; before the vehicle completes the current task, the vehicle computing system can select a vehicle service assignment for the autonomous vehicle to address; ¶0060 the selected vehicle service assignment can be a second transportation service assignment that has a pick-up location in the vicinity of the drop-off location of a first transportation service assignment currently being addressed by the autonomous vehicle (still pre-broadcasting to service entities)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Laury to include receiving, by the computing device, delivery constraint data describing constraints associated with one or more tasks in the list of tasks, wherein the delivery constraint data is received from the delivery company as taught by Goldman. One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to modify Laury in in order to provide an AV with the flexibility to perform vehicle services for a plurality of service entities in an efficient manner (see ¶0029 of Goldman).
Laury in view of Goldman further in view of Panzica discloses:
accessing, by the computing device, location constraint data describing constraints associated with one or more locations of one or more tasks in the list of tasks, wherein location constraint data includes one or more location constraints or time-based constraints determined based on stored map data of one or more locations associated with the list of tasks;
Laury in view of Goldman discloses accessing, by the computing device, location constraint data describing constraints associated with one or more locations of one or more tasks in the list of tasks, wherein location constraint data includes one or more location constraints or time-based constraints determined of one or more locations associated with the list of tasks: (see above limitations disclosing the time-based constraint and location based constraint data broadcasted to the service entities). Laury in view of Goldman does not explicitly disclose accessing, by the computing device, location constraint data describing constraints associated with one or more locations of one or more tasks in the list of tasks, wherein location constraint data includes one or more location constraints or time-based constraints determined based on stored map data of one or more locations associated with the list of tasks. Panzica suggests or discloses this limitation/concept: (Panzica ¶0084 disclosing the memory storing map data and constraint data; see also ¶0088, ¶0107, ¶0170). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Laury in view of Goldman to include accessing, by the computing device, location constraint data describing constraints associated with one or more locations of one or more tasks in the list of tasks, wherein location constraint data includes one or more location constraints or time-based constraints determined based on stored map data of one or more locations associated with the list of tasks as taught by Panzica. One of ordinary skill in the art before the effective filing date of the claimed invention would have been motivated to modify Laury in view of Goldman in order to implement constraints on particular areas that should be either included or excluded, thus affording efficient distribution of fleet resources (see ¶0038 of Panzica).
Claims 18 and 19 are directed to a computing device and non-transitory computer-readable medium, respectively. Claims 18 and 19 recite limitations that are parallel in nature as those addressed above for claim 1, which is directed towards a method. Claims 18 and 19 are therefore rejected for the same reasons as set forth above for claim 1. Furthermore, claims 18 and 19 recite:
(Claim 18): A computing device, the computing device comprising: one or more processors; and a computer-readable memory, wherein the computer-readable memory stores instructions that, when executed by the one or more processors, cause the computing device to perform operations comprising: (Laury ¶0014 disclosing the invention can be embodied in a special purpose computer or data processor that is specifically programmed, configured, or constructed to perform one or more of the computer-executable instructions explained in detail herein. Indeed, the terms “computer” and “computing device,” as used generally herein, refer to devices that have a processor and non-transitory memory, like any of the above devices, as well as any data processor or any device capable of communicating with a network. Data processors include programmable general-purpose or special-purpose microprocessors, programmable controllers, application-specific integrated circuits (ASICs), programming logic devices (PLDs), graphics processing units (GPUs), or the like, or a combination of such devices. Computer-executable instructions may be stored in memory, such as random access memory (RAM), read-only memory (ROM), flash memory, or the like, or a combination of such components. Computer-executable instructions may also be stored in one or more storage devices such as magnetic or optical-based disks, flash memory devices, or any other type of non-volatile storage medium or non-transitory medium for data)
(Claim 19): A non-transitory computer-readable medium storing instructions that, when executed by one or more computing devices, cause the one or more computing devices to perform operations comprising: (Laury ¶0014 disclosing the invention can be embodied in a special purpose computer or data processor that is specifically programmed, configured, or constructed to perform one or more of the computer-executable instructions explained in detail herein. Indeed, the terms “computer” and “computing device,” as used generally herein, refer to devices that have a processor and non-transitory memory, like any of the above devices, as well as any data processor or any device capable of communicating with a network. Data processors include programmable general-purpose or special-purpose microprocessors, programmable controllers, application-specific integrated circuits (ASICs), programming logic devices (PLDs), graphics processing units (GPUs), or the like, or a combination of such devices. Computer-executable instructions may be stored in memory, such as random access memory (RAM), read-only memory (ROM), flash memory, or the like, or a combination of such components. Computer-executable instructions may also be stored in one or more storage devices such as magnetic or optical-based disks, flash memory devices, or any other type of non-volatile storage medium or non-transitory medium for data)
Claim 2: The computer-implemented method of claim 1, further comprising: receiving, by the computing device and from one or more delivery recipients, recipient constraint data; wherein the optimized delivery route is generated, at least in part, based on the recipient constraint data. (Laury ¶0028 disclosing the delivery recipient orders or requests the payload; the recipient location can be determined based on…a recipient address provided by the delivery recipient as a part of the order/request (recipient constraint); ¶0029 disclosing based on the recipient location (delivery constraint), the delivery management system can determine one or more delivery locations, each location representing where the delivery recipient can access the autonomous delivery vehicle and the requested payload; delivery management system can determine each of the delivery locations as one of the stop locations (e.g., a predetermined geographical location where a vehicle can stop without interrupting the flow of traffic, where a person can approach and access the vehicle, such as a shoulder, a drive way, a parking lot or spot, etc.) closest to the recipient location(thus the location constraint is relative to the task of accessing the vehicle and payload at the delivery/recipient location; delivery management system can determine each the delivery locations as a location designated by the corresponding delivery recipient (e.g., a preferred location pre-identified by the delivery recipient or identified at the time of the order/request; ¶0032 based on the delivery locations delivery management system can calculate the delivery route including the pickup location and/or one or more of the delivery locations of the requested payload; ¶0040 delivery management system can group multiple delivery missions on one delivery route for picking up items from multiple locations, delivering to multiple locations, or a combination thereof (e.g., including one or more pickup locations and/or including one or more delivery locations); delivery management system can group the delivery missions using the optimization mechanism; also ¶0054 disclosing the delivery management system can receive an order detail from the merchant interface mechanism, the user device; order detail can include permission to access private property (e.g., for entering driveways, parking lots, etc.), special accessibility options during payload retrieval (such as based on end-user recipient requests including disabilities or physical constraints), etc.; ¶0055 disclosing that based on the order detail, the delivery management system can generate a delivery mission (e.g., machine-readable data/instructions) for picking up and/or transporting the requested payload to the corresponding delivery location, and ¶0056 disclosing that in generating the delivery mission, the system can determine an appropriate pickup location, etc.)
Claim 3: The computer-implemented method of claim 1, wherein delivery constraint data includes, for one or more tasks in the list of tasks, data indicating one or more time or location-based constraints associated with the task. (Laury ¶0042 disclosing the delivery management system can assign the delivery mission and update the delivery route based on remaining amount of fuel/charge or the available travel range/distance of the selected vehicle, time-requirements of remaining delivery missions (e.g., delivery promise time, condition of the payload, etc.); ¶0062 disclosing the delivery management system can access a database that includes predetermined time requirements, dimensions, shape, weight, etc. for potentially deliverable items to determine physical descriptions of the ordered item that the system uses to determine the loading profile; see also ¶0063 disclosing the delivery management system can determine the loading profile based on selecting a compartment that satisfies the size or preservation (e.g., temperature and/or time); ¶0103 disclosing the delivery management system can use an optimization engine that considers the ordered item or a type thereof, pickup and/or delivery locations, corresponding regions, currently available vehicles in the region, status (e.g., current location, available range, remaining cargo space, loaded cargo items, time restriction or condition, such as hot/cold delivery, of loaded cargo items, etc.))
Claim 5: The computer-implemented method of claim 1,
wherein location c