DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
This action is in reply to the amendments and remarks filed on 12 September 2025.
Claim 17 has been amended.
Claims 6 and 7 were previously canceled.
Claims 1-5 and 8-20 are currently pending and have been examined.
Response to Amendment
Applicant’s amendments fail to address the typographical errors previously objected to. Those objections are respectfully maintained.
Applicant’s amendments are insufficient to overcome the 112, 101 and 102 rejections previously raised. These rejections are respectfully maintained and updated below as necessitated by the amendments to the claims.
Response to Arguments
Applicant’s arguments filed on 12 September 2025 have been fully considered but are not persuasive.
Regarding the 112, the amendments to claim 17 do not in any way impact the 112 rejection of Claim 19. The amendments do not actively recite receiving the second request in Claim 17, which is the issue that was raised in Claim 19. How can an initiation be based on a second request, when a second request is not within the scope of the parent claim? Appropriate clarification and correct are required.
Regarding the 101, applicant argues that the claims encompass subject matter that integrates the alleged judicial into a practical application and the rejection fails to comply with the 2019 PEG. Examiner respectfully disagrees.
The full two step analysis was applied when examining the claims based on the most recent MPEP publications and memos establishing guidance. The claims are interpreted as reciting an abstract idea that falls within the designated abstract idea groupings since the claims illustrate a series of steps for managing interactions related to requesting and dispatching by identifying and evaluating factors. The additional elements set forth in the claims are specific identified as being a processing device and memory which merely apply the abstract idea, and therefore do not set forth meaningful limitations that implement the abstract idea beyond generally linking it to a technological environment. Performing an optimization “by a computer” is also considered to fall within the mental processes grouping. There are no steps set forth that integrate specific technological elements that are essential to the ability to execute the claimed methodology, nothing in the claims realizes how the control, adjustments or initiation of adjustments or operations is performed meaningfully with technological elements. The claims merely manipulate and optimize periods of time, i.e. dispatch windows, by evaluating constraints from requests, these functions could be done the same way manually by a human dispatcher, thus the computer acts merely as a tool. Adjusting the operation of a connected appliance, storing instructions, and using sensors to gather data do not transform the claims into a patent eligible invention. The additional elements were reconsidered under step 2B and do not amount to significantly more since they merely apply the exception or illustrate well-understood, routine and conventional activities as is supported by the case law from the cited portions of the MPEP. The claims do not set forth a particular machine, there is no support of specific programming, etc. that constitutes a particular machine, but instead merely recites a high level processing device and couped memory to perform operations. The specification in at least 0016-0017] recites that:
Processing device 210 can be a number of processors, a multi-processor core, or some other type of processor, depending on the particular implementation. Further, processor 210 can be implemented using a number of heterogeneous processor systems in which a main processor is present with secondary processors on a single chip. As another illustrative example, processor 210 can be a symmetric multi- processor system containing multiple processors of the same type. [0017] Memory 220 and/or storage 290 may be accessible by processor 210, thereby enabling processing device 210 to receive and execute instructions stored on memory 220 and/or on storage 290. Memory 220 can be, for example, a random access memory (RAM) or any other suitable volatile or non-volatile computer readable storage medium. In addition, memory 220 can be fixed or removable. Storage 290 can take various forms, depending on the particular implementation. For example, storage 290 can contain one or more components or devices. For example, storage 290 can be a hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above. Storage 290 also can be fixed or removable.
This simply describes generic processing devices and does not set forth any sort of particularly programmed or configured machine that is required for the execution of the claimed functions. The 101 rejection is respectfully maintained.
Regarding the 102 rejection, applicant argues that the cited references fails to teach based on the received one or more inputs originating from the sensor, the one or more inputs being associated with the second request, initiating, with respect to the received first request and within the dispatch window as computed based on the one or more constraints and with respect to the first request, a first adjustment of a first operation of a connected appliance with respect to the first request. Examiner respectfully disagrees.
The applied art rejection is based on the broadest reasonable interpretation of the claimed invention. Claiming “with respect to” a received request and/or “based on the one or more constraints”, “based on the received one or more inputs” does not significantly limit the interpretation of the claimed invention. There is no specification detailing how the received request impacts initiating or how the other described limitations form a basis for claimed functions. Garden in at least [0004-0007, 0012, 0016, 0018, 0047-0048, 0068, 0070, 0092-0093, 0098, 0103] and at least Fig. 7 illustrate how different orders going to different delivery locations are received, estimated times of arrival are determined, adjustments are made to the multiple cooking units for the different destinations’ orders, the ETA is dynamically adjusted for actual travel conditions and then the temperature and cooking time can be adjusted again. Garden in at least [0004-0007, 0012, 0016, 0018 and 0047-0048] describes determining revised routes for vehicles in response to the receipt of a new order or change in a previously received order not yet delivered, the routine module and/or the cooking module may use location information to statically or dynamically create and/or update delivery itinerary, i.e. the computed dispatch window, by dynamically adjusting the delivery itinerary, i.e. adjusting a dispatch of the first and second request within the computed dispatch window based identifying an order, i.e. a second order request with new/adjusted cooking instructions, and adding that order to an already in route vehicle’s itinerary, i.e. adjusting based on constraints/operation of the appliance, and controlling the cooking conditions within the cooking units to reflect the updated expected arrival times at consumer locations, see also [0068, 0070, 0092-0093, 0098, 0103] and Figs. 5-7. The system in Garden is capable of dynamically adjusting all aspects of the delivery and cooking process continuously for multiple orders and operations and in response to any newly received information.
Applicant argues that updating the itinerary based on location information is not the same as initiating adjustment of an operation of an appliance with respect to the first and second requests. Examiner notes that the applicant has not invoked lexicography with respect to the term “dispatch” or “dispatch window”. Although the applicant argues that an itinerary is not a dispatch with a dispatch window, the examiner turns to the ordinary and accustomed meaning of “dispatch”. “Dispatch” can mean the act of sending something to a destination (verb – to dispatch) or merely the sending of something to a destination (noun – a dispatch). Thus, the broadest reasonable interpretation of adjusting a dispatch within the dispatch window includes the ability to adjust anything, any factor, constraint, criteria or data related to sending something to a destination. The claim does not define what the dispatch window is, how it is derived or how it limits the dispatch in any way. Thus, the ability to dynamically adjust both a temporal itinerary for deliveries and the cooking conditions relating to the delivery of the orders represents adjusting a dispatch within a dispatch window and adjusting a dispatch window according to a broadest reasonable interpretation of the terms “dispatch” and “dispatch window”.
The ability to dynamically control cooking conditions and cooking times based on revised or dynamically received requests, Garden describes determining revised routes for vehicles in response to the receipt of a new order or change in a previously received order not yet delivered, the routine module and/or the cooking module may use location information to statically or dynamically create and/or update delivery itinerary, i.e. the computed dispatch window, by dynamically adjusting the delivery itinerary, i.e. adjusting a dispatch of the first and second request within the computed dispatch window based identifying an order, i.e. a second order request, and adding that order to an already in route vehicle’s itinerary, i.e. adjusting based on constraints associated with a first request, and controlling the cooking conditions within the cooking units to reflect the updated expected arrival times at consumer locations, i.e. initiating adjustment of an operation of an appliance for requested deliveries on a delivery itinerary.
Applicant argues that the cited portions of the references aren’t the same as initiating an adjustment or operation of a connected appliance with request to the first request. Examiner respectfully disagrees. Garden teaches the ability to receive multiple requests, including updated or revised order information when an existing order is already in process or being dispatched, the system automatically adjusts and controls the cooking temperature, humidity or other oven related functions in response to the received requests to dynamically control and adjust the delivery itinerary of multiple requested orders while enroute [0004]. Thus, it teaches that based on a first and second request and constraints of a first and second request, the ability to initiate and adjust the appliance itself, i.e. the oven by changing and controlling multiple different oven operations, as well as the itinerary or dispatch window.
[0004-0018 and 0047-0048] describe the ability to dynamically determine estimated transit times for each vehicle to each of a plurality of destinations, i.e. a plurality of orders as well as controlling the oven and revising the itinerary and controls. During the route based on updates the estimated times can change, i.e. parameters of a second order may cause a first order to be delayed or altered, the parameters may change the dispatch for any of the orders within the group of orders out for delivery if the traffic along the route to an order’s destination is greater than originally anticipated, therefore the routes and delivery times, e.g. dispatch, may be altered or adjusted in some dynamic way based on continuously gathered information. Therefore, the broadest reasonable interpretation of adjusting a dispatch based on a second request is taught by the reference’s ability to dynamically determine estimated transit times and routes for delivery routes that accord for multiple coordinated deliveries.
Applicant argues that using location information to update an itinerary and ETA and control or adjust cooking conditions is not the same as initiating an adjustment to an appliance with respect to a first request and based on inputs from the sensor for a 2nd request. Examiner respectfully disagrees. Based on the broadest reasonable interpretation of the claims, Garden describes the ability to dynamically adjust both the itinerary and cooking conditions for multiple orders, being prepared in multiple ovens and being delivered to multiple destinations, based on dynamically received inputs sensed from the ovens themselves as well as the actual travel conditions the delivery vehicles are undergoing and updated order information. Figs. 5-7 exemplify how the appliances or cooking temperatures and conditions are adjusted or set with respect to a first request, and then the inputs from the ovens are dynamically monitored such that when an additional order is received or a second order being prepared in a second oven is added to or already on the itinerary then the ovens are adjusted for cooking the second order for a different delivery destination and the controls on the first oven could also be modified to meet the planned ETA.
Applicant’s arguments are more specific than the broadest reasonable interpretation of the limitations set forth in the claims. The claims broadly recite making adjustments “based on” different inputs and requests but do not specify what exactly is adjusted, how the adjustments are done or what the basis of such an adjustment is, such as how the different types of data associated with the request could be utilized to alter the operation or dispatch. The 102 rejection is respectfully maintained and updated below as necessitated by the amendments to the claims.
Claim Objections
Claim 1 and 17 are objected to because of the following informalities: grammatical and typographical errors. Amended claim 1 recites receiving a second request that is “difference” and should state “different”. Additionally, both claims 1 and 17 recite in the initiating step “initiating…with respect to the second request with respect to which the one or more inputs originating from the sensor were received”. The duplicate recitation of “with respect to” is interpreted as a typographical error. Appropriate corrections are required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 19 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 19 recites limitations for performing different functions “based on the second request”. It is unclear when or how these functions can be performed because the active recitation of the receipt of the second request does not occur in independent claim 17, the claim merely recites receiving inputs originating from a sensor associated with a second request. Therefore, it is unclear what constitutes the second request, since the independent claim merely receive inputs related to or associated with a second request, but the request itself is not received as part of the actively recited method, thus it occurs outside of the scope of the Claim. It is not clear how the initiation of an adjustment of an operation or dispatch of a second request can be adjusted based on the second request when receipt of the second request is not actively part of the claimed methodology. Examiner recommends amending Claim 17 to recite “receiving one or more inputs originating from a sensor indicating a second request” or some similarly supported language to overcome this rejection, the mere association of inputs with a second request are not functionally equivalent. Appropriate correction and clarification are required.
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-5 and 8-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
The independent claims recite the limitations for receiving first and second requests, identifying constraints associated with the requests, based new requests and on the constraints computing and adjusting a dispatch window and initiating a second operation. These limitations, as drafted, illustrate a process that, under its broadest reasonable interpretation, illustrates certain methods of organizing human activity because they set forth steps that manage the interactions, e.g. deliveries, for commercial interactions, purchase orders. Receiving requests/orders with constraints, inputs from a sensor and using those to determine a dispatch window, i.e. a window of time or itinerary, that can be adjusted based on another request and initiate a second operation illustrate a process that manages behavior or interactions between people since the overall process relates to receiving an order from a purchaser with designated criteria and determining a dispatch (i.e. schedule/itinerary) with designated time frames for delivering the order which can be adjusted when additional orders are received and initiating those operations/deliveries. Initiating an adjustment of an operation of an appliance, adjusting an appliance and/or initiating a second operation are manual tasks that illustrates rules or instructions for a person to perform a task of adjusting an appliance or starting a delivery or other task and thus illustrate a certain method of organizing human activity in that the steps manage personal behavior. The claims do not set forth any particular additional elements that perform the initiating or operation adjustment nor do they describe how such an initiation or adjustment would be accomplished using a designated automated or computerized process implementation. The steps when considered individually can also be interpreted as mental processes since receiving requests and identifying constraints illustrate mere observations, then using the constraints as a basis for determining and adjusting a window illustrates making an evaluation that could be done the same way mentally or with the use of manual pencil/paper. But for the processing device and coupled memory that apply the operations, nothing in the claim precludes the steps from being done in the mind. The mere nominal recitation of a generic processing device and memory that causes the system to perform the steps does not take the claim out of the abstract idea groupings. Thus, the claims recite an abstract idea.
This judicial exception is not integrated into a practical application. The claims recite a processing device coupled to a memory that store instructions to execute the claimed methodology. The system that performs the receiving, identifying, computing, initiating and adjusting steps is recited at a high level of generality and merely automates the steps. Receiving inputs from a sensor can also be considered insignificant extra solution activity in that it is mere data gathering. Each of the additional limitations are no more than mere instructions to apply the exception using generic computer components. The combination of these additional elements is no more than mere instructions to apply the exception using a generic computer component. Accordingly, even in combination, these additional elements do not integrate the abstract idea into a practical application. 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 with respect to Step 2A Prong 2 above, the additional elements in the claims amount to no more than mere instructions to apply the exception using a generic computer component. The same analysis applies here in 2B and does not provide an inventive concept.
For the receiving inputs from a sensor that was considered extra solution activity in Step 2A above, this has been re-evaluated in step 2B and determined to be well understood, routine and conventional activity in the field. The specification does not provide any indication that the receiving is done by anything other than a generic off the shelf computer component and the Symantec, TLI and OIP Techs court decisions in MPEP 2106.05 d indicate that the mere collection, receipt or transmission of data over a network is well understood, routine and conventional when it is claimed in a merely generic manner, as it is here.
Dependent claims 2-5, 8-16 and 18-19 are dependent upon and include all the limitations of the independent claims and therefore recite the same abstract idea. The addition limitations merely narrow the abstract concepts by describing the request as an order, describing additional “identifying” or observation mental process steps, additional adjusting a dispatch steps which are further schedule modifications and illustrate certain method of organizing human activity since they relate to a schedule for managing behavior, i.e. delivery, and describe causing the system to perform or initiate operations which is also considered a certain method of organizing human activity since the operations include adjusting a schedule, so causing a system to adjust a schedule or initiating a schedule adjustment, without any additional elements or meaningful implementation is merely using a computer to manage a schedule of human behavior for delivering an order. Initiating an adjustment of an operation of a connected appliance again illustrate adjusting a scheduling operation of an appliance and does not illustrate a functional control or adjustment of the appliance itself, the actual control of the appliance is not within the scope of the system’s functionality. Receiving inputs from sensors illustrates insignificant extra solution data gathering when evaluated under Step 2A Prong 2 since it illustrates a collection function recited at a high level of generality. When reconsidered under Step 2B it is determined to be well-understood, routine and convention activity in the field. The specification does not indicate that the ability to receive inputs from sensors requires anything other than generic, off-the-shelf computer components and the Symantec, TLI and OIP Techs court decisions in MPEP 2106.05(d) indicate that mere collection or receive of data is a well-understood, routine and conventional function when it is claimed in a merely generic manner, as it is here.
For these reasons, there is no inventive concept and claims 1-6 and 8-20 are not patent eligible.
Claim Rejections - 35 USC § 102
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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-5 and 8-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Garden (US 2016/0162833).
As per Claim 1 Garden teaches:
A system comprising: a processing device; and a memory coupled to the processing device and storing instructions that, when executed by the processing device, cause the system to perform operations (Garden Fig. 1 and at least [0072-0073] illustrate and describe a distributed computing environment with program modules that store executable instructions using local or remote processors, microprocessors, digital signal processors and controllers) comprising:
receiving a first request (Garden in at least [0040] the controller or system devices are used to coordinate the receipt or generation of food orders; the order entry module can receive orders placed by consumers as is illustrated in at least Figs. 1 and 2A, see also [0108, 0112, 0114]);
identifying one or more constraints associated with the first request (Garden in at least [0041] describes how the controller includes algorithms able to correlate and associate the order of food items in a constrained geographic area, over the course of a defined temporal period, and/or during one or more defined events, see also [0108, 0112, 0114]);
based on the one or more constraints, computing a dispatch window with respect to the first request (Garden in at least [0042] the estimated delivery time can be based on the time to produce the ordered items plus transit time, estimated delivery times may take into account factors such as cook time, road congestions, traffic, time of day, etc.);
receiving a second request that is difference from the first request (Garden in at least [0040 and 0042] describes coordinating the receipt or generation of a plurality of food item orders placed by consumers, [0059] describes how the delivery itinerary lists a number of consumer delivery destinations for multiple received orders)
receiving one or more inputs originating from a sensor, [the one or more inputs being] associated with the second request (Garden in at least [0012, 0016 and 0046] describe portable cooking and delivery system elements that include a transducer, i.e. sensor, positioned to sense at least one operational condition of at least one of the ovens and coupled to the radio element of the system to provide signals to the remote stationary source, cooking conditions within each cooking unit are controlled and communicated to the controller via a network, the provided cooking condition signals from multiple ovens are inputs originating from a sensor associated with a second request because each oven is associated with preparation of food for a different order request/delivery destination, [0040 and 0042] describes coordinating the receipt or generation of food item orders placed by consumers, e.g. first and second orders, [0059] describes how the delivery itinerary lists a number of consumer delivery destinations for multiple received orders); and
based on the received one or more inputs originating from a sensor associated with the second request and the one or more constraints associated with the first request, adjusting a dispatch of the first (and second) request within the computed dispatch window (Garden [0012, 0016, 0018 and 0046-0048] describe determining revised routes for vehicles in response to the receipt of a new order or change in a previously received order not yet delivered, the routine module and/or the cooking module may use location information to statically or dynamically create and/or update delivery itinerary, i.e. the computed dispatch window, by dynamically adjusting the delivery itinerary, i.e. adjusting a dispatch of the first and second request within the computed dispatch window based identifying an order, i.e. a second order request, and adding that order to an already in route vehicle’s itinerary, i.e. adjusting based on constraints associated with a first request, and controlling the cooking conditions within the cooking units to reflect the updated expected arrival times at consumer locations, see also [0068, 0070, 0092-0093, 0098, 0103] and Figs. 5-7 showing how based on received oven conditions from multiple ovens associated with preparations of food for multiple different delivery locations for different orders and received travel conditions, dynamically updating estimated time to arrival, e.g. dispatch, and temperatures/cooking conditions ) and
initiating a second operation with respect to the second request with respect to which the one or more inputs originating from the sensor were received based on the dispatch window as computed with respect to the first request (Garden [0043] describes the ability to utilize automated or semi-automated systems upon receipt or generation of food item order data indicative of a particular order/order constraints to perform tasks such as kneading and forming dough or spreading sauce and cheese. Examiner notes that the operations can also be reasonably interpreted as mere schedule adjustments as is taught by adjusting a dispatch, e.g. schedule, above, [0062] further describes the controller and/or cooking module that can establish, control or adjust cooking conditions in each unit based on available cooking time, these conditions can be determined by the controller, real time updating can cause the controller and/or routine module to autonomously update the delivery itinerary, new available times can be determined and adjusted throughout the delivery process to reflect newly estimated times of arrival using the dynamically updated delivery itinerary and recalculated available cooking times).
As per Claim 2 Garden teaches:
wherein the first request comprises an order (Garden [0040] describes how the controller is used to coordinate the receipt or generation of food item orders from consumers).
As per Claim 3 Garden teaches:
wherein identifying one or more constraints comprises computing the one or more constraints based on the first request (Garden [0041] describes how the controller includes algorithms able to correlate and associate the order of food items in a constrained geographic area, over the course of a defined temporal period, and/or during one or more defined events).
As per Claim 4 Garden teaches:
wherein identifying one or more constraints comprises computing a second constraint based on a first constraint (Garden [0041] describes how the controller includes algorithms able to correlate and associate the order of food items in a constrained geographic area, over the course of a defined temporal period, and/or during one or more defined events, [0047-0048] the routine module and or cooking module may use the location information to statically or dynamically create and/or update delivery itinerary information and estimated time of arrival, ).
As per Claim 5 Garden teaches:
wherein the memory further stores instructions to cause the system to perform operations comprising initiating a first operation with respect to the first request (Garden [0043] describes the ability to utilize automated or semi-automated systems upon receipt or generation of food item order data indicative of a particular order/order constraints to perform tasks such as kneading and forming dough or spreading sauce and cheese. Examiner notes that the operations can also be reasonably interpreted as mere schedule adjustments as is taught by adjusting a dispatch, e.g. schedule, above).
As per Claim 8 Garden teaches:
wherein adjusting a dispatch of the first request comprises adjusting a first operation with respect to the first request based on the second request (Garden [0062] the controller and/or cooking module can establish, control and adjust cooking conditions in each cooking unit based at least in part on available cooking time, real time updating reflecting traffic or current location information can be used to update the delivery itinerary and new available cooking times for each consumer destination location can be determined by the controller, routine module and cooking module or any combination based on updated delivery itinerary, cooking conditions can be adjusted in each cooking unit throughout the delivery process to reflect newly estimates times of arrival and recalculated availability).
As per Claim 9 Garden teaches:
wherein adjusting a dispatch of the first request comprises initiating, based on the second request, an adjustment of an operation of a connected appliance with respect to the first request (Garden [0062] the controller and/or cooking module can establish, control and adjust cooking conditions in each cooking unit based at least in part on available cooking time, real time updating reflecting traffic or current location information can be used to update the delivery itinerary and new available cooking times for each consumer destination location can be determined by the controller, routine module and cooking module or any combination based on updated delivery itinerary, cooking conditions can be adjusted in each cooking unit throughout the delivery process to reflect newly estimates times of arrival and recalculated availability, [0046] describes how cooking conditions are controlled enroute and can be utilized and adjusted to determine optimal delivery itineraries, estimated delivery times and available cooking times).
As per Claim 10 Garden teaches:
wherein the memory further stores instructions to cause the system to perform operations comprising identifying one or more constraints associated with the second request (Garden in at least [0041] describes how the controller includes algorithms able to correlate and associate the order of food items in a constrained geographic area, over the course of a defined temporal period, and/or during one or more defined events).
As per Claim 11 Garden teaches:
wherein adjusting a dispatch of the first request comprises adjusting a first operation with respect to the first request based on one or more constraints associated with the second request (Garden [0062] the controller and/or cooking module can establish, control and adjust cooking conditions in each cooking unit based at least in part on available cooking time, real time updating reflecting traffic or current location information can be used to update the delivery itinerary and new available cooking times for each consumer destination location can be determined by the controller, routine module and cooking module or any combination based on updated delivery itinerary, cooking conditions can be adjusted in each cooking unit throughout the delivery process to reflect newly estimates times of arrival and recalculated availability, [0046] describes how cooking conditions are controlled enroute and can be utilized and adjusted to determine optimal delivery itineraries, estimated delivery times and available cooking times).
As per Claim 12 Garden teaches:
wherein adjusting a dispatch of the first request comprises adjusting a dispatch of the first request based on receipt of the second request and one or more other requests (Garden [0018, 0040 and 0047-0048] describe determining revised routes for vehicles in response to the receipt of a new order or change in a previously received order not yet delivered, the routine module and/or the cooking module may use location information to statically or dynamically create and/or update delivery itinerary by dynamically adjusting the delivery itinerary and controlling the cooking conditions within the cooking units to reflect the updated expected arrival times at consumer locations).
As per Claim 13 Garden teaches:
wherein adjusting a dispatch of the first request comprises adjusting a dispatch of the first request based on receipt of the second request and an availability of one or more fulfillment resources (Garden [0042 and 0044] describe the controller being coupled to an inventory control or enterprise business system such that inventory of ingredients or other items is maintained with devised levels within the production module, estimated delivery time may reflect the availability of the ordered food item on a delivery vehicle that is pre-staged in a particular area, [0009] describes pre-order stocking or caching that may be based on previous demand and may be specific to food item, day, time geographic location or events).
As per Claim 14 Garden teaches:
wherein adjusting a dispatch of the first request comprises adjusting a dispatch of the first request based on receipt of the second request and a determined location of one or more fulfillment resources (Garden [0042, 0044, and 0047] describe the controller being coupled to an inventory control or enterprise business system such that inventory of ingredients or other items is maintained with devised levels within the production module, estimated delivery time may reflect the availability of the ordered food item on a delivery vehicle that is pre-staged in a particular area, the routing or cooking modules may use location information to statically or dynamically create and/or update delivery itinerary information and estimated times and use that information to control or adjust cooking conditions in units, [0009] describes pre-order stocking or caching that may be based on previous demand and may be specific to food item, day, time geographic location or events,).
As per Claim 15 Garden teaches:
wherein adjusting a dispatch of the first request comprises adjusting a dispatch of the first request and the second request (Garden [0018, 0040 and 0047-0048] describe determining revised routes for vehicles in response to the receipt of a new order or change in a previously received order not yet delivered, the routine module and/or the cooking module may use location information to statically or dynamically create and/or update delivery itinerary by dynamically adjusting the delivery itinerary and controlling the cooking conditions within the cooking units to reflect the updated expected arrival times at consumer locations) .
As per Claim 16 Garden teaches:
wherein adjusting a dispatch of the first request comprises adjusting the dispatch window based on the second request (Garden [0018, 0040 and 0047-0048] describe determining revised routes for vehicles in response to the receipt of a new order or change in a previously received order not yet delivered, the routine module and/or the cooking module may use location information to statically or dynamically create and/or update delivery itinerary by dynamically adjusting the delivery itinerary and controlling the cooking conditions within the cooking units to reflect the updated expected arrival times at consumer locations).
As per Claims 17-20 the limitations are substantially similar to those set forth in Claims 1, 5 and 9 and are therefore rejected based on the reasons and rationale set forth in the rejection of Claims 1, 5, and 9 above. With regards to the computer readable medium Garden further teaches in at least [0072-0073] computer executable instructions stored and executable by a processor, processing device or computer. Garden further teaches:
receiving a second request (Garden [0040 and 0042] describes coordinating the receipt or generation of food item orders placed by consumers, e.g. first and second orders, [0059] describes how the delivery itinerary lists a number of consumer delivery destinations for multiple received orders);
based on the received one or more inputs originating from the sensor associated with the second request, initiating, with respect to the received first request and within the dispatch window as computed based on the one or more constraints and with respect to the first request, a first adjustment of a first operation of a connected appliance with respect to the first request (Garden [0004-0007, 0012, 0016, 0018 and 0047-0048] and Figs. 5-7 describe and illustrate determining revised routes for vehicles in response to the receipt of a new order or change in a previously received order not yet delivered, the routine module and/or the cooking module may use location information to statically or dynamically create and/or update delivery itinerary, i.e. the computed dispatch window, by dynamically adjusting the delivery itinerary, i.e. adjusting a dispatch of the first and second request within the computed dispatch window based identifying an order, i.e. a second order request, and adding that order to an already in route vehicle’s itinerary, i.e. adjusting based on constraints associated with a first request, and controlling the cooking conditions within the cooking units preparing the first and second request’s orders to reflect the updated expected arrival times at consumer locations, i.e. initiating adjustment of an operation of an appliance for requested deliveries on a delivery itinerary with request to the first request, see also [0068, 0070, 0092-0093, 0098, 0103]); and
based on the received second request, adjusting a first operation of a connected appliance with respect to the received first request based on one or more constraints associated with the received second request/initiating a second operation with respect to the second request with respect to which the one or more inputs originating from the sensor associated with the second request were received based on the dispatch window as computed based on the one or more constraints and with respect to the first request (Garden [0004-0007, 0012, 0016, 0018 and 0047-0048] describe determining revised routes for vehicles in response to the receipt of a new order or change in a previously received order not yet delivered, the routine module and/or the cooking module may use location information to statically or dynamically create and/or update delivery itinerary, i.e. the computed dispatch window, by dynamically adjusting the delivery itinerary, i.e. adjusting a dispatch of the first and second request within the computed dispatch window based identifying an order, i.e. a second order request, and adding that order to an already in route vehicle’s itinerary, i.e. adjusting based on constraints associated with a first request, and controlling the cooking conditions, e.g. changing the time, temperature, etc. within the cooking units to reflect the updated expected arrival times at consumer locations, see also [0068, 0070, 0092-0093, 0098, 0103] and Figs. 5-7), and
based on the adjustment of the first operation of the connected appliance, adjusting a dispatch window of the first request and the second request within the dispatch window (Garden [0004-0007, 0012, 0016, 0018 and 0047-0048] describe determining revised routes for vehicles in response to the receipt of a new order or change in a previously received order not yet delivered, the routine module and/or the cooking module may use location information to statically or dynamically create and/or update delivery itinerary, i.e. the computed dispatch window, by dynamically adjusting the delivery itinerary, i.e. adjusting a dispatch of the first and second request within the computed dispatch window based identifying an order, i.e. a second order request, and adding that order to an already in route vehicle’s itinerary, i.e. adjusting based on constraints associated with a first request, and controlling the cooking conditions within the cooking units to reflect the updated expected arrival times at consumer locations, see also [0068, 0070, 0092-0093, 0098, 0103] and Figs. 5-7).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEPHANIE Z DELICH whose telephone number is (571)270-1288. The examiner can normally be reached on Monday - Friday 7-3:30.
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, Rutao Wu can be reached on 571-272-6045. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/STEPHANIE Z DELICH/Primary Examiner, Art Unit 3623