CTFR 17/643,855 CTFR 94913 Detailed Action 12-151 AIA 26-51 12-51 Status of Claims 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. This Action is in reply to the Amendment filed on 2/6/2026. Claims 1-20 are currently pending and have been examined. Claims 1, 3, 11-12, 16-17 have been amended. Claim Rejection - 35 USC § 101 07-04-01 AIA 07-04 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 an abstract idea without significantly more. First, it is determined whether the claims are directed to a statutory category of invention. In the instant case, claims 1-10 are directed to a process, claims 11-15 are directed to an article of manufacture, and claims 16-20 are directed to a machine. Therefore, claims 1-20 are directed to statutory subject matter under Step 1 as described in MPEP 2106 (Step 1: YES). The claims are then analyzed to determine whether the claims are directed to a judicial exception. In determining whether the claims are directed to a judicial exception, the claims are analyzed to evaluate whether the claims recite a judicial exception (Prong One of Step 2A), as well as analyzed to evaluate whether the claims recite additional elements that integrate the judicial exception into a practical application of the judicial exception (Prong Two of Step 2A). Claims 1, 11, and 16 recite at least the following limitations that are believed to recite an abstract idea: receiving a shopping support request from a user requesting at least one product to be purchased and delivered to the user while the user travels along a scheduled route; identifying, responsive to determining that the shopping support request does not designate a delivery place and a delivery time, a plurality of delivery places on the scheduled route of the user and a plurality of delivery times based on a first set of factors, wherein the identifying comprises setting an upper limit of delivery time based on a type of the at least one product; determining at least one shopper candidate who can purchase and deliver the at least one product to the user at an identified delivery place at an identified delivery time by matching a second set of factors; generating a list comprising a plurality of optimal support execution methods for purchasing and delivering the at least one product; presenting to the at least one shopper candidate, a list comprising the plurality of optimal support execution methods; responsive to receiving an acceptance of the shopping support request from the at least one shopper candidate, selecting at least one shopper from the at least one shopper candidate and a support execution method from the list; sending a support task to the at least one shopper as an alert notification, wherein the support task details the selected support execution method; enabling the at least one shopper to execute the shopping support request; and updating one or more details of the support task by: detecting a third set of factors affecting timely completion of the shopping support request; and responsive to detecting the a third set of factors, updating, during the execution of the support task, the support execution method, to purchase and deliver the at least one product to the user, wherein the updating comprises recomputing at least one support task constraint including a purchase place, the delivery place, the delivery time, or a method of transportation that affects the timely completion of the shopping support request without recomputing unaffected constraints. The above limitations recite the concept of order delivery support. These limitations, under their broadest reasonable interpretation, fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas, enumerated in MPEP 2106, in that they recite commercial interactions, e.g. sales activities/behaviors, and managing personal behavior or relationships or interactions between people, e.g., following rules or instructions. Accordingly, under Prong One of Step 2A, claims 1-20 an abstract idea (Step 2A, Prong One: YES). Prong Two of Step 2A is the next step in the eligibility analyses and looks at whether the abstract idea is integrated into a practical application. This requires an additional element or combination of additional elements in the claims to apply, rely on, or user the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the exception. In this instance, the claims recite the additional elements of: The method being computer-implemented One or more processors Steps being performed dynamically A computer program product, comprising: one or more non-transitory computer readable storage media and program instructions stored on the one or more non-transitory computer readable storage media having stored therein program instructions that, when executed by one or more processors, cause the one or more processors to perform steps A computer system comprising: one or more computer processors; one or more computer readable storage media; program instructions collectively stored on the one or more computer readable storage media for execution by at least one of the one or more computer processors Program instructions However, these elements do not amount to an improvement in the functioning of a computer or any other technology or technical field; apply the judicial exception with, or by use of, a particular machine; or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort to monopolize the exception. In addition, the recitations are recited at a high level of generality and also do not amount to an improvement in the functioning of a computer or any other technology or technical field; apply the judicial exception with, or by use of, a particular machine; or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort to monopolize the exception. The dependent claims also fail to recite elements which amount to an improvement in the functioning of a computer or any other technology or technical field; apply the judicial exception with, or by use of, a particular machine; or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort to monopolize the exception. For example, claims 2-3, 6-8, 10, 12-14, and 17-19 are directed to the abstract idea itself and do not amount to an integration according to any one of the considerations above. As for claims 4-5, 9, 15, and 20, these claims are similar to the independent claims except that they recite the further additional elements of a user interface, a user computing device, and a QR code. These additional elements are recited at a high level of generality and also do not amount to an improvement in the functioning of a computer or any other technology or technical field; apply the judicial exception with, or by use of, a particular machine; or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort to monopolize the exception. Therefore the dependent claims do not create an integration for the same reasons. Step 2B is the next step in the eligibility analyses and evaluates whether the claims recite additional elements that amount to an inventive concept (i.e., “significantly more”) than the recited judicial exception. According to Office procedure, revised Step 2A overlaps with Step 2B, and thus, many of the considerations need not be re-evaluated in Step 2B because the answer will be the same. In Step 2A, several additional elements were identified as additional limitations: The method being computer-implemented One or more processors Steps being performed dynamically A computer program product, comprising: one or more non-transitory computer readable storage media and program instructions stored on the one or more non-transitory computer readable storage media having stored therein program instructions that, when executed by one or more processors, cause the one or more processors to perform steps A computer system comprising: one or more computer processors; one or more computer readable storage media; program instructions collectively stored on the one or more computer readable storage media for execution by at least one of the one or more computer processors Program instructions These additional limitations, including the limitations in the dependent claims, do not amount to an inventive concept because they were already analyzed under Step 2A and did not amount to a practical application of the abstract idea. Therefore, the claims lack one or more limitations which amount to an inventive concept in the claims. For these reasons, the claims are rejected under 35 U.S.C. 101. 07-06 AIA 15-10-15 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 07-20-02-aia AIA 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 Rejection – 35 USC § 103 07-20-aia AIA 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. 07-23-aia AIA 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 non- obviousness. 07-21-aia AIA Claim s 1-4, 6, 8, 10-12, 14, 16-17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Haken (US 20030125963 A1), hereinafter Haken, in view of Fan et al (US 20200396227A1), hereinafter Fan, and further in view of Rellas et al (US 20140201001 A1), hereinafter Rellas . Regarding Claim 1 , Haken discloses a computer-implemented method comprising: receiving, by one or more processors, a shopping support request from a user requesting at least one product [ food items ] to be purchased and delivered to the user while the user travels along a scheduled route [ travel plans ] (Haken: “At step I, a customer … uses a wireless data terminal to place an order for food …with the server…the customer indicates his choice of food items, a time or range of times when he would prefer to have the items delivered to him and his travel plans around the delivery time or times.” [0026] – Customers may walk, drive, or otherwise travel [0004]. ); identifying, by the one or more processors, responsive to determining that the shopping support request does not designate a delivery place and a delivery time, a plurality of delivery places [ rendezvous/delivery positions ] on the scheduled route of the user and a plurality of delivery times [ rendezvous times ] based on a first set of factors (Haken: “At step V, the server applies the rendezvous calculation methods …to determine potential positions for a delivery” [0028] – “At step VII the list of candidate rendezvous positions is transmitted to the customer's terminal.” [0029] – “calculate candidate rendezvous times and locations.” [0024]), wherein the identifying comprises: setting, by the one or more processors, an upper limit of delivery time (Haken: “the customer might indicate that he desired delivery of a chicken sandwich anytime before 12:30 pm” [0026]); determining, by the one or more processors, at least one shopper candidate [delivery person] who can purchase and deliver the at least one product to the user at an identified delivery place at an identified delivery time by matching a second set of factors (Haken: “the Server also checks whether one or more deliver persons are available to make a delivery from each facility during the relevant time frame. …a taxi driver would be available to make a delivery starting at 12:20” [0027]); sending, by the one or more processors, a support task to the at least one shopper as an alert notification, wherein the support task details a support execution method (Haken: “At step VIII, the server places the order with the relevant facility and delivery person to initiate preparation and delivery of the food. The order to the delivery person will generally include specification of a particular route from the preparation facility to the selected rendezvous position that was determined during the rendezvous calculation Step.” [0031]); enabling, by the one or more processors, the at least one shopper to execute the shopping support request (Haken: “the server places the order with the relevant facility and delivery person to initiate preparation and delivery of the food” [0031] – “If the customer or delivery person deviate from their expected routes, or from their expected progress along the expected routes, the server calculates a new expected delivery time and advises transmits messages to advise the customer and delivery person” [0032]); and updating, by the one or more processors, dynamically one or more details of the support task by: detecting a third set of factors [ status / deviation ] affecting timely completion of the shopping support request; and responsive to detecting the third set of factors, dynamically updating, during the support task, the support execution method [ new rendezvous ], to purchase and deliver the at least one product to the user, wherein the updating comprises recomputing at least one support task constrain including a purchase place, the delivery place, the delivery time, or a method of transportation that affects the timely completion of the shopping support request without recomputing unaffected constraints (Haken: “At step IX, the server regularly polls the facility Selected for preparing the food, the customer's terminal and the delivery person's terminal to monitor the status of the order and the locations of the customer and delivery person. If the customer or delivery person deviate from their expected routes, or from their expected progress along the expected routes, the Server calculates a new expected delivery time and advises transmits messages to advise the customer and delivery person. If necessary the server can calculate a new rendezvous location based on the progress of the actors.” [0032]). While Haken teaches setting an upper limit of delivery time [0026] & placing the order with a selected delivery person and presenting route information to the rendezvous point to the delivery person [0031], it does not specifically teach that the upper limit of delivery time is based on a type of the at least one product, or the steps of generating, by the one or more processors, a list comprising a plurality of optimal support execution methods for purchasing and delivering the at least one product; presenting, by the one or more processors, to the at least one shopper candidate, a list comprising the plurality of optimal support execution methods; or responsive to receiving an acceptance of the shopping support request from the at least one shopper candidate, selecting, by the one or more processors, at least one shopper from the at least one shopper candidate and a support execution method from the list. However, Fan teaches techniques to facilitate the delivery of an item to a user (Fan: Abstract), including: setting, by the one or more processors, an upper limit of delivery time based on a type of the at least one product (Fan: “the item may correspond with a food item or perishable item that may require an expedited transportation timeline between a merchant location and a consumer location in order to maintain the freshness of the item.” [0071] – “An ETA deadline that is missed with conventional systems may not affect the item, whereas a perishable item may become unusable and/or frustrate the consumer. When perishable items are transported, the system described herein may factor in freshness of the item. The system may account for the physical transportation of item to maintain freshness of the item in association with an expedited timeline, and in some examples, rely on additional data streams to identify and resolve a delivery issue prior to affecting the freshness and usability of the perishable item.” [0029]); generating, by the one or more processors, a list comprising one or more optimal support execution methods for purchasing and delivering the at least one product (Fan: “ arrival estimator engine 228 may transmit electronic communications with a routing server that can identify a shortest or fastest route between two locations (e.g., using a route or traffic assignment algorithm” [0113] – “ provide an electronic offer based on a type of path corresponding with transportation of item. For example, in association with constraint engine 222 , offer module 218 may be configured to determine the type of path (e.g., traversed by a motor vehicle, non-motor vehicle, or pedestrian, etc.) corresponding with the transportation of the item. The type of path may be compared with a fleet user profile to identify a subset of fleet users that match the transportation needed for the path between the merchant location and the consumer location.” [0080]); presenting, by the one or more processors, to the at least one shopper candidate [ fleet user ], a list comprising the one or more optimal support execution methods (Fan: “provide information to fleet user device 300, including viewing an electronic offer to physically transport an item and/or accepting the electronic offer by interacting with input elements” [0124] – “provide an electronic offer based on a type of path corresponding with transportation of item. … determine the type of path (e.g., traversed by a motor vehicle, non-motor vehicle, or pedestrian, etc.) corresponding with the transportation of the item. The type of path may be compared with a fleet user profile to identify a subset of fleet users that match the transportation needed for the path between the merchant location and the consumer location.” [0080] – “the subset of fleet users may be identified by distance or travel time between the movable location of the fleet user device, size or weight of an item in comparison with the transportation mode of the fleet user (e.g., large items over a threshold weight cannot be carried by bike messengers, etc.), or other factors. ” [0094]); and responsive to receiving an acceptance of the shopping support request from the at least one shopper candidate, selecting, by the one or more processors, at least one shopper from the at least one shopper candidate and a support execution method from the list (Fan: “The pickup started identifier may correspond with an acceptance of the electronic offer by a fleet user device. The acceptance of the electronic offer may correlate the physical transportation of the item from the merchant location to the consumer location to a particular fleet user device.” [0075] – “the tracking system may receive updated data associated with the between the home location of the fleet user, the merchant location, and consumer location. The estimated arrival time may be adjusted based on any delay identified in the updated data.” [0102]). It would have been obvious to one of ordinary skill in the art before the effective filing date of invention to combine these references because the results would be predictable. Specifically, Haken would continue to teach setting the upper limit of delivery time, sending, by the one or more processors, a support task to the at least one shopper as an alert notification, wherein the support task details the one or more optimal support execution methods, except that now it would also teach that the upper limit of delivery time is based on a type of the at least one product; generating, by the one or more processors, a list comprising one or more optimal support execution methods for purchasing and delivering the at least one product presenting, by the one or more processors, to the at least one shopper candidate, the list comprising one or more optimal support execution methods; and responsive to receiving an acceptance of the shopping support request from the at least one shopper candidate, selecting, by the one or more processors, at least one shopper from the at least one shopper candidate and a support execution method from the list, according to the teachings of Fan. This is a predictable result of the combination. In addition, it would have been obvious to one of ordinary skill in the art before the effective filing date of invention to combine these references because it would result in an improved ability deliver items while proactively stopping issues (Fan: [0002]). While Haken/Fan do not specifically teach that the one or more optimal support execution methods comprise a plurality of optimal support execution methods, Rellas teaches delivery systems [0006-0008], including that the list comprises a plurality of optimal support execution methods (Rellas: “the driver application displays each order assigned to a particular store in separate list elements 2702. A single list element is comprised of one order. … the driver can indicate that he is beginning a given driver step … the driver steps include: authorized and paid…loading…enroute” [0220-0226] – “The driver may be able to select a route to the delivery address, e.g., by pressing on route 1 4402, route 2 4404 or route 3 4406. Once the driver has selected his desired route, he can get directions by pressing the “start” button 4408.” [0236] – see Figure 44. ). It would have been obvious to one of ordinary skill in the art before the effective filing date of invention to combine these references because the results would be predictable. Specifically, Haken/Fan would continue to teach generating, by the one or more processors, a list comprising one or more optimal support execution methods for purchasing and delivering the at least one product; presenting, by the one or more processors, to the at least one shopper candidate, a list comprising the one or more optimal support execution methods, except that now it would also teach that the list comprises a plurality of optimal support execution methods, according to the teachings of Rellas. This is a predictable result of the combination. In addition, it would have been obvious to one of ordinary skill in the art before the effective filing date of invention to combine these references because it would result in an improved ability to facilitate a faster and smoother delivery of products (Rellas: [0115]). Regarding Claim 2 , Haken/Fan/Rellas teach the computer-implemented method of claim 1, wherein the first set of factors includes at least one of: position information about at least one purchase place for the at least one shopper candidate to purchase the at least one product, position information about at least one delivery place to transfer the at least one product from the at least one shopper candidate to the user, information about at least one transportation method to the delivery place for the at least one shopper candidate, information about at least one transportation method to the delivery place for the user, information about at least one delivery time to transfer the at least one product from the at least one shopper candidate to the user, a scheduled travel route of the user, and a scheduled travel route of the at least one shopper candidate (Haken: “The order information is entered into a system server that also has access to databases that include: maps and other routing information, various locations where the food order can be prepared, estimates of expected preparation time for the food items ordered, location and availability of potential deliver persons, and information about other pending and anticipated orders. Using this information the server chooses a preparation location and delivery person and then calculates a candidate rendezvous position where the customers and the delivery person can meet to effect delivery of the food.” [0006] – “bicycle delivery person could be restrained to routes along regular Streets, …a delivery person traveling on foot can move freely through most malls and Woods…Obstacles may be time dependent. For example, park gates and Shopping malls may close at certain hours, traffic and parking rules may be time limited, and certain Streets may be judged to be unsafe at various times of the day.” [0023] – See also [0027] ). Regarding Claim 3 , Haken/Fan/Rellas teach the computer-implemented method of claim 1, wherein identifying, responsive to determining that the shopping support request does not designate the delivery place and the delivery time, the plurality of delivery places on the scheduled route of the user and the plurality of delivery times based on the first set of factors further comprises: responsive to determining that the purchase place is not designated by the user in the shopping support request, locating, by the one or more processors, at least one purchase place for the at least one shopper candidate to purchase the at least one product (Haken: “At step V, the server applies the rendezvous calculation methods …to determine potential positions for a delivery” [0028] – “At step VII the list of candidate rendezvous positions is transmitted to the customer's terminal.” [0029] – “calculate candidate rendezvous times and locations.” [0024] - “At step VIII, the server places the order with the relevant facility and delivery person to initiate preparation and delivery of the food. The order to the delivery person will generally include specification of a particular route from the preparation facility to the selected rendezvous position that was determined during the rendezvous calculation Step.” [0031]); excluding, by the one or more processors, any shopper candidate who cannot travel to the at least one purchase place to purchase the at least one product (Haken: “the Server also checks whether one or more deliver persons are available to make a delivery from each facility during the relevant time frame.” [0027]); responsive to determining that the delivery place is not designated by the user in the shopping support request, locating, by the one or more processors, at least one delivery place to transfer the at least one product from the at least one shopper candidate to the user (Haken: “At step VII the list of candidate rendezvous positions is transmitted to the customer's terminal.” [0029] – “The customer and delivery person meet at the rendezvous site and delivery is made.” [0033]); excluding, by the one or more processors, any shopper candidates who cannot deliver the at least one product to the user at the at least one delivery place (Haken: “The database may also maintain information about any Special constraints that affect a particular delivery person. For example, a delivery person who is wearing a uniform or other type of dress may not be permitted in Some buildings or an armed delivery person may be excluded from Some public buildings and transportation facilities.” [0022]); determining, by the one or more processors, whether the delivery time is designated by the user in the shopping support request (Haken: “For example, at 11:45 am the customer might indicate that he desired delivery of a chicken sandwich anytime before 12:30 pm and that he plans to remain at his present location until 12:00 noon and then travel by walking to the fountain 24 in park 20.” [0026]); responsive to determining that the delivery time is not designated by the user in the shopping support request, setting, by the one or more processors, an upper limit of the delivery time (Haken: “For example, at 11:45 am the customer might indicate that he desired delivery of a chicken sandwich anytime before 12:30 pm and that he plans to remain at his present location until 12:00 noon and then travel by walking to the fountain 24 in park 20.” [0026]); proposing, by the one or more processors, the plurality of delivery times to the user (Haken: “The customer's terminal exchanges messages with the Server and displays a Series of questions or menus through which the customer indicates … a time or range of times when he would prefer to have the items delivered to him” [0026]); enabling, by the one or more processors, the user to select the delivery time from the plurality of delivery times proposed (Haken: “the customer might indicate that he desired delivery … before 12:30 pm.” [0026]); and excluding, by the one or more processors, any shopper candidates who cannot deliver the at least one product to the user by the delivery time selected (Haken: “the Server also checks whether one or more deliver persons are available to make a delivery from each facility during the relevant time frame. …a taxi driver would be available to make a delivery starting at 12:20” [0027]), wherein Fan further teaches: determining, by the one or more processors, whether a transportation method is constrained by the type of the at least one product; responsive to that determining the transportation method is constrained by the type of the at least one product, excluding, by the one or more processors, any shopper candidates who cannot use a non-constrained transportation method to deliver the at least one product to the user (Fan: “the subset of fleet users may be identified by distance or travel time between the movable location of the fleet user device, size or weight of an item in comparison with the transportation mode of the fleet user (e.g., large items over a threshold weight cannot be carried by bike messengers, etc.), or other factors. ” [0094]); and setting, by the one or more processors, the upper limit of the delivery time (Fan: “the item may correspond with a food item or perishable item that may require an expedited transportation timeline between a merchant location and a consumer location in order to maintain the freshness of the item.” [0071] – “An ETA deadline that is missed with conventional systems may not affect the item, whereas a perishable item may become unusable and/or frustrate the consumer. When perishable items are transported, the system described herein may factor in freshness of the item. The system may account for the physical transportation of item to maintain freshness of the item in association with an expedited timeline, and in some examples, rely on additional data streams to identify and resolve a delivery issue prior to affecting the freshness and usability of the perishable item.” [0029]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Fan with Haken/Rellas for the reasons identified above with respect to claim 1. Regarding Claim 4 , Haken/Fan/Rellas teach the computer-implemented method of claim 3, wherein locating the at least one delivery place to transfer the at least one product from the at least one shopper candidate to the user further comprises: responsive to determining that the delivery will be direct, locating, by the one or more processors, the plurality of delivery places on the scheduled route of the user where a direct delivery can be performed (Haken: “At step V, the server applies the rendezvous calculation methods …to determine potential positions for a delivery” [0028] – “At step VII the list of candidate rendezvous positions is transmitted to the customer's terminal.” [0029] – “calculate candidate rendezvous times and locations.” [0024] – “one or more points along the customers anticipated route of travel” [0008]); proposing, by the one or more processors, the plurality of delivery places on the scheduled route of the user where the direct delivery can be performed to the user through a user interface of a user computing device (Haken: “At step VII the list of candidate rendezvous positions is transmitted to the customer's terminal. The customer chooses a one of the positions from the list for delivery and transmits a confirmation message to the Server.” [0030]); and enabling, by the one or more processors, the user to select the delivery place from the plurality of delivery places proposed through the user interface of the user computing device (Haken: “At step VII the list of candidate rendezvous positions is transmitted to the customer's terminal. The customer chooses a one of the positions from the list for delivery and transmits a confirmation message to the Server.” [0030]). Regarding Claim 6 , Haken/Fan/Rellas teach the computer-implemented method of claim 1, wherein the second set of factors includes at least one of: position information about at least one purchase place for the at least one shopper candidate to purchase the at least one product and information about at least one transportation method to the delivery place for the at least one shopper candidate (Haken: “the Server also checks whether one or more deliver persons are available to make a delivery from each facility during the relevant time frame. …a taxi driver would be available to make a delivery starting at 12:20” [0027]). Regarding Claim 8 , Haken/Fan/Rellas teach the computer-implemented method of claim 1, wherein the list comprising the one or more optimal support execution methods includes at least one of: position information about an optimal purchase place for one or more shopper candidates to purchase the at least one product, position information about an optimal delivery place to transfer the at least one product from the at least one shopper candidate to the user, information about an optimal transportation method to the delivery place for the at least one shopper candidate, information about an optimal transportation method to the delivery place for the user , and information about an optimal delivery time to transfer the at least one product from the at least one shopper candidate to the user ( Fan: “provide information to fleet user device 300, including viewing an electronic offer to physically transport an item and/or accepting the electronic offer by interacting with input elements” [0124] – “provide an electronic offer based on a type of path corresponding with transportation of item. … determine the type of path (e.g., traversed by a motor vehicle, non-motor vehicle, or pedestrian, etc.) corresponding with the transportation of the item. The type of path may be compared with a fleet user profile to identify a subset of fleet users that match the transportation needed for the path between the merchant location and the consumer location.” [0080] – “the subset of fleet users may be identified by distance or travel time between the movable location of the fleet user device, size or weight of an item in comparison with the transportation mode of the fleet user (e.g., large items over a threshold weight cannot be carried by bike messengers, etc.), or other factors. ” [0094] – “the item may correspond with a food item or perishable item that may require an expedited transportation timeline between a merchant location and a consumer location in order to maintain the freshness of the item.” [0071]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Fan with Haken/Rellas for the reasons identified above with respect to claim 1. Regarding Claim 10 , Haken/Fan/Rellas teach the computer-implemented method of claim 1, wherein the third set of factors includes at least one of: a current weather forecast, a future weather forecast, a current traffic situation, a future traffic situation, a change in a transportation schedule, a change in an optimal transportation method to the delivery place for the at least one shopper, a change in an optimal transportation method to the delivery place for the user, and a trajectory pattern of a third party (Haken: “a delivery person traveling by automobile could be constrained to move along a route that principally utilizes Streets, highways and parking lots, Subject to various traffic restrictions” [0023] – “Delivery from a vehicle may be most effectively concluded in a parking lot and a sheltered, indoor delivery location maybe preferred on rainy days.” [0024] – “If the customer or delivery person deviate from their expected routes, or from their expected progress along the expected routes, the Server calculates a new expected delivery time and advises transmits messages to advise the customer and delivery person. If necessary the Server can calculate a new rendezvous location based on the progress of the actors.” [0032]). Regarding Claims 11-12 and 14 ¸ the limitations of claims 11-12 and 14 are closely parallel to the limitations of claims 1, 3 and 8, with the additional limitation of computer program product comprising: one or more computer readable storage media and program instructions stored on the one or more computer readable storage media (Haken: [0012]), and are rejected on the same basis. Regarding Claims 16-17 and 19, the limitations of claims 16-17 and 19 are closely parallel to the limitations of claims 1, 3, and 8, with the additional limitation of a computer system comprising: one or more computer processors; one or more computer readable storage media; program instructions collectively stored on the one or more computer readable storage media for execution by at least one of the one or more computer processors (Haken: [0012]), and are rejected on the same basis . 07-21-aia AIA Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Haken/Fan/Rellas, and further in view of Seaver et al (US 20200349511 A1), hereinafter Seaver . Regarding Claim 5 , Haken/Fan/Rellas teach the computer-implemented method of claim 3, wherein locating the at least one delivery place to transfer the at least one product from the at least one shopper candidate to the user further comprises: locating, by the one or more processors, a plurality of locations on the scheduled route of the user where a delivery can be performed (Haken: “At step V, the server applies the rendezvous calculation methods …to determine potential positions for a delivery” [0028] – “At step VII the list of candidate rendezvous positions is transmitted to the customer's terminal.” [0029] – “calculate candidate rendezvous times and locations.” [0024]); proposing, by the one or more processors, the plurality of locations on the scheduled route of the user where the delivery can be performed to the user through a user interface of a user computing device (Haken: “At step VII the list of candidate rendezvous positions is transmitted to the customer's terminal.” [0030] – “the Server also transmits a coded message to the customer's terminal which the customer can show to … confirm his identity before the food is turned over.” [0033]); and enabling, by the one or more processors, the user to select a location from the plurality of locations on the scheduled route of the user where the delivery can be performed through the user interface of the user computing device (Haken: “The customer chooses a one of the positions from the list for delivery and transmits a confirmation message to the Server.” [0030]), but do not specifically teach determining that the delivery will be indirect; or that the plurality of locations are lockers or dedicated storage facilities. However, Seaver teaches methods for delivering items from merchants (Seaver: Abstract), including determining that the delivery will be indirect; and that the plurality of locations are lockers or dedicated storage facilities (Seaver: “, if the results of the determination at 412 is then the process 400 proceeds to step 414 where a centralized hub / bus stop , a node , a pod , a temporary storage structure , a parcel locker , or similar device , can be used to efficiently handoff to a new delivery resource” [0092]). It would have been obvious to one of ordinary skill in the art before the effective filing date of invention to combine these references because the results would be predictable. Specifically, Haken/Fan/Rellas would continue to teach locating, by the one or more processors, a plurality of locations on the scheduled route of the user where a delivery can be performed, except that now it would also teach determining that the delivery will be indirect; and that the plurality of locations are lockers or dedicated storage facilities, according to the teachings of Seaver. This is a predictable result of the combination. In addition, it would have been obvious to one of ordinary skill in the art before the effective filing date of invention to combine these references because it would result in an improved ability for efficient and timely delivery of items (Seaver: [0002]) . 07-21-aia AIA Claim s 7, 13, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Haken/Fan/Rellas, and further in view of Smith et al (US 20210065111 A1), hereinafter Smith . Regarding Claim 7 , Haken/Fan/Rellas teach the computer-implemented method of claim 1, wherein determining the at least one shopper candidate who can purchase and deliver the at least one product to the user at the identified delivery place at the identified delivery time by matching the second set of factors further comprises: identifying, by the one or more processors, a first shopper candidate who can execute the shopping support request from a list of previous shopper candidates stored in a database (Haken: “The Server might determine that the Sandwich could be prepared either at facility 80, where a taxi driver would be available to make a delivery starting at 12:20; at facility 74, where a bicycle delivery person could be available to make a delivery anytime after 12:00; at facility 73, where a pedestrian delivery person could be available at 12:25 or at facility 71, where the food could be prepared by 12:15 but no delivery person could be available before 12:30.” [0027] – “The current location of each delivery person, his status and his mode of transportation are maintained in a database on the Server.” [0022]); determining, by the one or more processors, whether the first shopper candidate can execute the shopping support request independently, wherein executing the shopping support request independently comprises the at least one shopper candidate purchasing and delivering the at least one product to the user at the identified delivery place at the identified delivery time (Haken: “The Server might determine that the Sandwich could be prepared either at facility 80, where a taxi driver would be available to make a delivery starting at 12:20; at facility 74, where a bicycle delivery person could be available to make a delivery anytime after 12:00; at facility 73, where a pedestrian delivery person could be available at 12:25 or at facility 71, where the food could be prepared by 12:15 but no delivery person could be available before 12:30.” [0027]); responsive to determining that the first shopper candidate cannot execute the shopping support request independently, identifying, by the one or more processors, a second shopper candidate who can execute the shopping support request from the list of previous shopper candidates stored in the database (Haken: “The Server might determine that the Sandwich could be prepared either at facility 80, where a taxi driver would be available to make a delivery starting at 12:20; at facility 74, where a bicycle delivery person could be available to make a delivery anytime after 12:00; at facility 73, where a pedestrian delivery person could be available at 12:25 or at facility 71, where the food could be prepared by 12:15 but no delivery person could be available before 12:30.” [0027]); determining, by the one or more processors, whether the second shopper candidate can execute the shopping support request independently (Haken: “The Server might determine that the Sandwich could be prepared either at facility 80, where a taxi driver would be available to make a delivery starting at 12:20; at facility 74, where a bicycle delivery person could be available to make a delivery anytime after 12:00; at facility 73, where a pedestrian delivery person could be available at 12:25 or at facility 71, where the food could be prepared by 12:15 but no delivery person could be available before 12:30.” [0027]); searching, by the one or more processors, for an additional shopper candidate who can execute the shopping support request from the list of previous shopper candidates stored in the database (Haken: “The Server might determine that the Sandwich could be prepared either at facility 80, where a taxi driver would be available to make a delivery starting at 12:20; at facility 74, where a bicycle delivery person could be available to make a delivery anytime after 12:00; at facility 73, where a pedestrian delivery person could be available at 12:25 or at facility 71, where the food could be prepared by 12:15 but no delivery person could be available before 12:30.” [0027]); and responsive to determining that there are no additional shopper candidates who can execute the shopping support request, generating, by the one or more processors, the list of shopper candidates who can execute the shopping support request (Haken: “The Server might determine that the Sandwich could be prepared either at facility 80, where a taxi driver would be available to make a delivery starting at 12:20; at facility 74, where a bicycle delivery person could be available to make a delivery anytime after 12:00; at facility 73, where a pedestrian delivery person could be available at 12:25 or at facility 71, where the food could be prepared by 12:15 but no delivery person could be available before 12:30.” [0027]), but does not specifically teach responsive to determining that the second shopper candidate cannot execute the shopping support request independently, determining, by the one or more processors, whether the second shopper candidate can execute the shopping support request jointly with the first shopper candidate, wherein executing the shopping support request jointly with the first shopper candidate comprises the first shopper candidate purchasing the at least one product and the second shopper candidate delivering the at least one product to the user at the identified delivery place at the designated or identified delivery time or vice versa; or responsive to determining that the second shopper candidate can execute the shopping support request jointly with the first shopper candidate, adding, by the one or more processors, the first shopper candidate and the second shopper candidate as a single listing to a list of shopper candidates who can execute the shopping support request. However, Smith teaches mobility-as-a-service delivery routing systems (Smith: Abstract) including: responsive to determining that the second shopper candidate cannot execute the shopping support request independently, determining, by the one or more processors, whether the second shopper candidate can execute the shopping support request jointly with the first shopper candidate, wherein executing the shopping support request jointly with the first shopper candidate comprises the first shopper candidate purchasing the at least one product and the second shopper candidate delivering the at least one product to the user at the identified delivery place at the designated or identified delivery time or vice versa; and responsive to determining that the second shopper candidate can execute the shopping support request jointly with the first shopper candidate, adding, by the one or more processors, the first shopper candidate and the second shopper candidate as a single listing to a list of shopper candidates who can execute the shopping support request (Smith: “the item delivery module 250 may initiate delivery of the item 115 based on the revised delivery route by identifying and coordinating an exchange between two MaaS vehicles . To coordinate the exchange , the item delivery module 250 may , as an example , request one Maas vehicle drop off the item 115 at a depot and another MaaS vehicle pick up the item 115 at the depot to deliver the item 115 to the updated destination .” [0058] – A specific example is provided in [0063] ). It would have been obvious to one of ordinary skill in the art before the effective filing date of invention to combine these references because the results would be predictable. Specifically, Haken/Fan/Rellas would continue to teach responsive to determining that there are no additional shopper candidates who can execute the shopping support request, generating, by the one or more processors, the list of shopper candidates who can execute the shopping support request, except that now it would also teach responsive to determining that the second shopper candidate cannot execute the shopping support request independently, determining, by the one or more processors, whether the second shopper candidate can execute the shopping support request jointly with the first shopper candidate, wherein executing the shopping support request jointly with the first shopper candidate comprises the first shopper candidate purchasing the at least one product and the second shopper candidate delivering the at least one product to the user at the identified delivery place at the designated or identified delivery time or vice versa; and responsive to determining that the second shopper candidate can execute the shopping support request jointly with the first shopper candidate, adding, by the one or more processors, the first shopper candidate and the second shopper candidate as a single listing to a list of shopper candidates who can execute the shopping support request, according to the teachings of Smith. This is a predictable result of the combination. In addition, it would have been obvious to one of ordinary skill in the art before the effective filing date of invention to combine these references because it would result in an improved ability to mor efficiently transport products to a desired destination (Smith: [0002]). Regarding Claims 13 and 18 , the limitations of claims 13 and 18 are closely parallel to the limitations of claim 7 and are rejected on the same basis . 07-21-aia AIA Claim s 9, 15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Haken/Fan/Rellas, and further in view of Kovalova et al (US 20220261744 A1), hereinafter Kovalova . Regarding Claim 9 , Haken/Fan/Rellas teach the computer-implemented method of claim 1, wherein enabling the at least one shopper to execute the shopping support request further comprises: issuing, by the one or more processors, a transfer code to the user and the at least one shopper (Haken: “the Server also transmits a coded message to the customer's terminal which the customer can show to delivery person to confirm his identity before the food is turned over.” [0033]); enabling, by the one or more processors, the user and the at least one shopper to complete a transfer of the at least one product using the transfer code issued (Haken: “the Server also transmits a coded message to the customer's terminal which the customer can show to delivery person to confirm his identity before the food is turned over. The delivery person transmits a message that informs the Server that the transaction has been completed” [0033]); sending, by the one or more processors, a final demand to the user, wherein the final demand is an itemized account of a cost of the purchase of the at least one product and the delivery of the at least one product to the user; enabling, by the one or more processors, the user to make a payment to satisfy the final demand (Haken: “If the order has been charged to a credit card or other account, the Server can also Send a confirming message to the customers pda that Verifies payment and authorizes the delivery person to turn-over the order to the customers.” [0007] – “The confirmation message may include authorization to charge the customer's account or credit card for the items and delivery Service provided.” [0030]), wherein Fan further teaches sending, by the one or more processors, a receipt confirmation of the purchase of the at least one product to the user (Fan: “provide one or more electronic communications to a consumer user device corresponding with one or more status identifiers of the item” [0182] – “the status identifier may correspond with an item available identifier, an item ordered identifier, a pickup started identifier, a pickup imminent identifier, a drop off started identifier, or a drop off imminent identifier.” [0072] – See Figure 13 ). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Haken with Fan/Rellas for the reasons identified above with respect to claim 1. However, Haken/Fan/Rellas do not specifically teach the steps of sending, by the one or more processors, a QR code to the at least one shopper to purchase the at least one product at an optimal purchase place; enabling, by the one or more processors, the at least one shopper to purchase the at least one product at the optimal purchase place with the QR code; sending, by the one or more processors, a reward to the at least one shopper. However, Kovalova teaches third-party shopping and delivery systems (Kovalova: Abstract), including sending, by the one or more processors, a QR code to the at least one shopper [ picker ] to purchase the at least one product at an optimal purchase place; enabling, by the one or more processors, the at least one shopper to purchase the at least one product at the optimal purchase place with the QR code (Kovalova: “The PMA 112 also includes an image encoder 326 which encodes the contents of a basket into an image . For example , the image encoder 326 may encode a basket of goods ( with an identification of each item ) into a QR code which can then be scanned by an employee of the retailer 110 at check - out .” [0042] – “picker mobile application ( PMA ) ” [0009]); and sending, by the one or more processors, a reward to the at least one shopper (Kovalova: “the delivery management engine 216 may send instructions to the DMA on how to receive compensation” [0036] – “ delivery agents 114 may also be pickers 108 and work to both fulfill and deliver orders” [0023]). It would have been obvious to one of ordinary skill in the art before the effective filing date of invention to combine these references because the results would be predictable. Specifically, Haken/Fan/Rellas would continue to teach enabling, by the one or more processors, the user and the at least one shopper to complete the transfer using the transfer code issued, except that now it would also teach sending, by the one or more processors, a QR code to the at least one shopper to purchase the at least one product at an optimal purchase place; enabling, by the one or more processors, the at least one shopper to purchase the at least one product at the optimal purchase place with the QR code; sending, by the one or more processors, a reward to the at least one shopper, according to the teachings of Kovalova. This is a predictable result of the combination. In addition, it would have been obvious to one of ordinary skill in the art before the effective filing date of invention to combine these references because it would result in an improved ability to allow customers to receive orders of items from delivery agents (Kovalova: [0002]). Regarding Claims 15 and 20 , the limitations of claims 15 and 20 are closely parallel to the limitations of claim 9 and are rejected on the same basis . Response to Arguments 07-37 Applicant’s arguments filed 2/6/2026 have been fully considered but are not persuasive. Claim Rejection – 35 §USC 101 Applicant argues that the claims are not directed to an abstract idea, but “instead to a specific, computer-implemented method hat [sic] controls how a support task is executed and dynamically updated during real-world user travel,” arguing that the “claim recites a structured sequence of processor-implemented operations that go well beyond mental processes or fundamental business practices,” such as requiring “the computing system to construct multiple alternative executable task workflows, each defining concrete operation parameters such as purchase place, delivery place, deliver time, and transportation method, based on matched factors associated with the user’s scheduled route, product-dependent constraints, and shopper capabilities.” Applicant argues that steps are recited to occur “during execution of a support task,” and that the system “dynamically updates the executing support method,” which “defines how the system itself responds to changing real-world conditions while the task is being performed,” such that “the claim thus focuses on execution-time control and state management.” Examiner disagrees. With reference to the rejection above, the argued operations, such as the argued ability to “construct multiple alternative executable task workflows, each defining concrete operation parameters such as purchase place, delivery place, deliver time, and transportation method, based on matched factors associated with the user’s scheduled route, product-dependent constraints, and shopper capabilities,” are part of the abstract idea itself. Similarly, the ability to update delivery operations during a delivery based on “changing real-world conditions” is part of the abstract idea for managing/supporting order fulfillment, including managing the timing and state of that order fulfillment. The recitation of computer-related additional elements, such as steps being stated to be performed “dynamically,” and operations being implemented by a generic processor, provide only a general linking to computer technology [MPEP 2106.05(f)]. Applicant further argues that the claim “avoids unnecessary reprocessing and completes task in a more efficient and effective way,” thereby “preserving execution continuity and completed task stages.” Applicant argues that the claim “improves the operation of the computerized system itself by reducing unnecessary re-computation, preserving execution state, and enabling real-time task modification in a mobile environment.” Examiner disagrees. The alleged improvements, e.g. avoiding unnecessary re-calculation of delivery criteria and the ability to update a delivery task during its performance, are part of the abstract idea itself, and are therefore at best a business improvement stemming solely from the abstract idea. The additional elements, rather than integrating this abstract idea into a practical application by reciting an improvement in the functioning of a computer or an improvement to a technical field, are invoked merely as instructions to apply this abstract idea to a technological environment, e.g. to be performed “by a processor,” “dynamically,” etc. [MPEP 2106.05(f)]. At best, the additional elements offer only the improved speed or efficiency inherent to a generic computing device, and do not integrate the abstract idea into a practical application [MPEP 2106.05(a)]. Applicant argues that claims 11 and 16 are eligible under 101 “due to analogous recitations contained therein,” and that the dependent claims “are patentable at least by virtue of their respective dependencies” on the independent claims. Examiner disagrees for the reasons addressed in the rejection and response above. Claim Rejection – 35 USC §103 Applicant argues that “Haken does not disclose …dynamically updating, during execution of the support task, the support execution method itself, including actionable constraints such as a purchase place, delivery place, delivery time, or method of transportation.” Examiner disagrees. While the delivery task is being performed, Haken monitors the status to detect a deviation from a route or from an expected progress associated with a particular execution of the delivery task [0032]. The system recalculates only a delivery time or a delivery location, while not recalculating a transportation means, for instance, and updates the delivery task, during its operation, to adjust the location or time of delivery. Applicant’s arguments with respect to the newly amended “list including a plurality of optimal support execution methods, from which one is selected,” 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. Specifically, the rejection above points to newly relied-upon reference Rellas to teach the list of a plurality of support execution methods as claimed. Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure : Shakes et al (US 20140052661 A1) teaches systems for temporary delivery locations for purchased goods to be delivered to a customer without diverting from their route. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 THOMAS JOSEPH SULLIVAN whose telephone number is (571)272-9736. The examiner can normally be reached on Mon - Fri 8-5 PT. 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, Marissa Thein can be reached on 571-272-6764. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /T.J.S./Examiner, Art Unit 3689 /VICTORIA E. FRUNZI/Primary Examiner, Art Unit 3689 5/29/2026 Application/Control Number: 17/643,855 Page 2 Art Unit: 3689 Application/Control Number: 17/643,855 Page 3 Art Unit: 3689 Application/Control Number: 17/643,855 Page 4 Art Unit: 3689 Application/Control Number: 17/643,855 Page 5 Art Unit: 3689 Application/Control Number: 17/643,855 Page 6 Art Unit: 3689 Application/Control Number: 17/643,855 Page 7 Art Unit: 3689 Application/Control Number: 17/643,855 Page 8 Art Unit: 3689 Application/Control Number: 17/643,855 Page 9 Art Unit: 3689 Application/Control Number: 17/643,855 Page 10 Art Unit: 3689 Application/Control Number: 17/643,855 Page 11 Art Unit: 3689 Application/Control Number: 17/643,855 Page 12 Art Unit: 3689 Application/Control Number: 17/643,855 Page 13 Art Unit: 3689 Application/Control Number: 17/643,855 Page 14 Art Unit: 3689 Application/Control Number: 17/643,855 Page 15 Art Unit: 3689 Application/Control Number: 17/643,855 Page 16 Art Unit: 3689 Application/Control Number: 17/643,855 Page 17 Art Unit: 3689 Application/Control Number: 17/643,855 Page 18 Art Unit: 3689 Application/Control Number: 17/643,855 Page 19 Art Unit: 3689 Application/Control Number: 17/643,855 Page 20 Art Unit: 3689 Application/Control Number: 17/643,855 Page 21 Art Unit: 3689 Application/Control Number: 17/643,855 Page 22 Art Unit: 3689 Application/Control Number: 17/643,855 Page 23 Art Unit: 3689 Application/Control Number: 17/643,855 Page 24 Art Unit: 3689 Application/Control Number: 17/643,855 Page 25 Art Unit: 3689 Application/Control Number: 17/643,855 Page 26 Art Unit: 3689
Prosecution Insights