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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Joint Inventors
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..
Response to Amendment
Claims 1, 6, 7, 11, 16, and 20 have been amended. No claims have been added or cancelled.
Response to Arguments
Applicant's arguments filed 02/27/2026 have been fully considered but they are not persuasive.
Applicant contends that intrinsic quality variability is absent from Studor. Examiner contends applicant is overstating the claimed language, and that Studor discloses the customized recipe specific to the first beverage robot.
[0008] A process profile may map a result of the process to the values of multiple variables (e.g., temperature, pressure, volume, or various characteristics of the input ingredients) over the time it takes to perform the process, and may be used to optimize the process to achieve a desired qualitative characteristic of the beverage or a component thereof. [0166] For example, these applications may allow a customer to choose either the closest kiosk, or their favorite kiosk, as the kiosk to produce their requested beverage(s). The applications may allow a customer to place an order for a single drink or for multiple drinks based on their own ordering history and favorite drinks, or from a menu of drinks available from the selected kiosk.
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(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.
Claim(s) 1-3, 6-13, 15-18, and 20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Studor et al. (US20170215631, referred to as Studor).
Regarding claim 1: Studor discloses: A method for operating a network of a plurality of beverage robots, the method comprising: receiving an order for a beverage from a first individual beverage robot from the plurality of beverage robots at a first store, wherein the beverage is associated with a customized recipe specific to the first store requiring one or more ingredients; identifying one or more second stores, wherein each individual second store has a second individual beverage robot available to prepare the beverage based on ingredients available at the second individual beverage robot; determining a first reception time at the first store, the first reception time associated with when a user would receive the beverage from the first store; for each individual second store in the one or more second stores determining a second reception time at the individual second store, the second reception time associated with when the user would receive the beverage from the individual second store; identifying, from the one or more second stores, a earlier second store based on the second reception time at the earlier second store being before the first reception time; presenting the earlier second store to the user to allow the user to choose between the first store and the earlier second store; and in response to a selection of the earlier second store from the user: checking information on ingredients available at the second individual beverage robot in the earlier second store, the information including a batch number or source identifier associated with raw data comprising at least one of an acidity level, sugar levels,or concentration information of the ingredients; calculating one or more adjustments to the customized recipe based on the raw data of the ingredients to account for variations in taste qualities to maintain flavor consistency of the beverage as if prepared by the first store; and sending an adjusted recipe to the second individual beverage robot at the earlier second store to cause the beverage to be prepared, ([0008] A process profile may map a result of the process to the values of multiple variables (e.g., temperature, pressure, volume, or various characteristics of the input ingredients) over the time it takes to perform the process, and may be used to optimize the process to achieve a desired qualitative characteristic of the beverage or a component thereof. [0166] customers may interact with the automated beverage generation systems described herein using customer applications (e.g., applications for the web and/or for Smartphones). In various embodiments. Such applications may perform (or enable the system to provide) any of a variety of scheduling related functions, including any or all of those described below. For example, these applications may allow a customer to choose either the closest kiosk, or their favorite kiosk, as the kiosk to produce their requested beverage(s). The applications may allow a customer to place an order for a single drink or for multiple drinks based on their own ordering history and favorite drinks, or from a menu of drinks available from the selected kiosk. In some embodiments, the applications may, based on GPS distance, routing, and/or traffic congestion information, enable the system to recommend a time and/or a location at which the drink(s) should be prepared and ready for pick up. The applications may allow a customer to select either their favorite time/location, or a time/location that was proposed by the system based on their location and other information (as described above). )
Regarding claim 2: Studor discloses: The method of claim 1,
Studor further discloses: wherein: determining the first reception time comprises calculating a travel time between a current location of the user and the first store; and for each individual second store in the one or more second stores, determining the second reception time comprises calculating a travel time between the current location of the user and the individual second store. ([0166] As previously noted, customers may interact with the automated beverage generation systems described herein using customer applications (e.g., applications for the web and/or for Smartphones). In various embodiments. Such applications may perform (or enable the system to provide) any of a variety of scheduling related functions, including any or all of those described below. For example, these applications may allow a customer to choose either the closest kiosk, or their favorite kiosk, as the kiosk to produce their requested beverage(s). The applications may allow a customer to place an order for a single drink or for multiple drinks based on their own ordering history and favorite drinks, or from a menu of drinks available from the selected kiosk. In some embodiments, the applications may, based on GPS distance, routing, and/or traffic congestion information, enable the system to recommend a time and/or a location at which the drink(s) should be prepared and ready for pick up. The applications may allow a customer to select either their favorite time/location, or a time/location that was proposed by the system based on their location and other information (as described above). If no GPS information is available, or in the case of a web application, the customer may simply select from a list of favorite times/locations or may input that information directly)
Regarding claim 3: Studor discloses: The method of claim 1,
Studor further discloses: wherein: determining the first reception time comprises checking a queue at the first individual beverage robot at the first store; and for each individual second store in the one or more second stores, determining the second reception time comprises checking a queue at the second individual beverage robot at the individual second store. ([0166] customers may interact with the automated beverage generation systems described herein using customer applications (e.g., applications for the web and/or for Smartphones). In various embodiments. Such applications may perform (or enable the system to provide) any of a variety of scheduling related functions, including any or all of those described below. For example, these applications may allow a customer to choose either the closest kiosk, or their favorite kiosk, as the kiosk to produce their requested beverage(s). The applications may allow a customer to place an order for a single drink or for multiple drinks based on their own ordering history and favorite drinks, or from a menu of drinks available from the selected kiosk. In some embodiments, the applications may, based on GPS distance, routing, and/or traffic congestion information, enable the system to recommend a time and/or a location at which the drink(s) should be prepared and ready for pick up. The applications may allow a customer to select either their favorite time/location, or a time/location that was proposed by the system based on their location and other information (as described above). [0180] if the automated kiosk does not have required ingredients and/or available resources needed to produce a requested beverage at the requested delivery time, the request may be declined, or the customer may be asked for authorization to direct the order to a different kiosk that is able to produce the beverage in the desired timeframe (e.g., if it is a remotely place order). 0181. As illustrated in FIG. 27, the method may include incorporating the accepted requests into a scheduling queue dependent on a requested or target delivery or pick up time for each request (e.g., a delivery or pick up time requested by customer or a target delivery time for a speculative or preemptive order request made by the master controller/ scheduler), as in 2730. The method may include beginning production of a particular beverage in the queue, as in 2740, and advancing production of the particular beverage, as resources are available (as in 2750). As illustrated in this example, a partially completed beverage may be staged between processes until resources are available for the next required step. In some embodiments, progress updates may be provided to the customer as production of the beverage advances. For example, updates may be displayed at the kiosk or provided to the customer remotely (e.g., through a web browser or ordering application on a remote computer or Smartphone). The particular beverage may be presented to the customer when it is completed, or staged at a “will-call area until customer arrives for pick up (or is otherwise available to take deliver of the beverage), as in 2760.)
Regarding claim 6: Studor discloses: The method of claim 5,
Studor further discloses: wherein the one or more adjustments are first adjustments, and wherein the method further comprises identifying one or more second adjustments to the recipe based on modifications to the customized recipe received with the order. ([0167] the applications may enable the system to take into account any lack of availability of the particular ingredients and additives or functions (e.g., due to the configuration of the equipment or the status or avail ability of various process modules) needed to process a specific drink at any location when recommending or accepting a particular kiosk order. In some embodiments, the information stored in a local or remote database about a customer's favorite drink may include a preferred location and/or retrieval time, which may be accessed by the appli cations to speed up a regular order (e.g., in the case of a commuter that has a regular schedule). Based on an algo rithm that takes into account historical and current loads (e.g., current and historical demand for beverages), the scheduler software executing in (or on behalf of) the kiosk may determine when to start processing the drink in order to meet the scheduled delivery time [0180] if the automated kiosk does not have required ingredients and/or available resources needed to produce a requested beverage at the requested delivery time, the request may be declined, or the customer may be asked for authorization to direct the order to a different kiosk that is able to produce the beverage in the desired timeframe (e.g., if it is a remotely place order). 0181. As illustrated in FIG. 27, the method may include incorporating the accepted requests into a scheduling queue dependent on a requested or target delivery or pick up time for each request (e.g., a delivery or pick up time requested by customer or a target delivery time for a speculative or preemptive order request made by the master controller/ scheduler), as in 2730. The method may include beginning production of a particular beverage in the queue, as in 2740, and advancing production of the particular beverage, as resources are available (as in 2750). As illustrated in this example, a partially completed beverage may be staged between processes until resources are available for the next required step. In some embodiments, progress updates may be provided to the customer as production of the beverage advances. For example, updates may be displayed at the kiosk or provided to the customer remotely (e.g., through a web browser or ordering application on a remote computer or Smartphone). The particular beverage may be presented to the customer when it is completed, or staged at a “will-call area until customer arrives for pick up (or is otherwise available to take deliver of the beverage), as in 2760.)
Regarding claim 7: Studor discloses: The method of claim 5,
Studor further discloses: wherein the batch number and/or source identifier associated with the ingredients is associated with one or more taste qualities of the ingredients. ([0167] the applications may enable the system to take into account any lack of availability of the particular ingredients and additives or functions (e.g., due to the configuration of the equipment or the status or avail ability of various process modules) needed to process a specific drink at any location when recommending or accepting a particular kiosk order. In some embodiments, the information stored in a local or remote database about a customer's favorite drink may include a preferred location and/or retrieval time, which may be accessed by the appli cations to speed up a regular order (e.g., in the case of a commuter that has a regular schedule). Based on an algo rithm that takes into account historical and current loads (e.g., current and historical demand for beverages), the scheduler software executing in (or on behalf of) the kiosk may determine when to start processing the drink in order to meet the scheduled delivery time [0180] if the automated kiosk does not have required ingredients and/or available resources needed to produce a requested beverage at the requested delivery time, the request may be declined, or the customer may be asked for authorization to direct the order to a different kiosk that is able to produce the beverage in the desired timeframe (e.g., if it is a remotely place order). 0181. As illustrated in FIG. 27, the method may include incorporating the accepted requests into a scheduling queue dependent on a requested or target delivery or pick up time for each request (e.g., a delivery or pick up time requested by customer or a target delivery time for a speculative or preemptive order request made by the master controller/ scheduler), as in 2730. The method may include beginning production of a particular beverage in the queue, as in 2740, and advancing production of the particular beverage, as resources are available (as in 2750). As illustrated in this example, a partially completed beverage may be staged between processes until resources are available for the next required step. In some embodiments, progress updates may be provided to the customer as production of the beverage advances. For example, updates may be displayed at the kiosk or provided to the customer remotely (e.g., through a web browser or ordering application on a remote computer or Smartphone). The particular beverage may be presented to the customer when it is completed, or staged at a “will-call area until customer arrives for pick up (or is otherwise available to take deliver of the beverage), as in 2760. [0150] One embodiment of a method for producing brewed beverages according to a multiple-variable process profile is illustrated by the flow diagram in FIG. 23. As illustrated as 2310 in this example, the method may include developing a multiple-variable process profile for each of one or more target beverages or for various processes used to produce those beverages, dependent on temperature, pressure, time, and/or other process inputs or environmental variables. For example, process profiles may be developed (e.g., empirically) for each of the processes involved in producing a beverage using a particular recipe and/or in order to achieve a desired qualitative result (e.g., a particular taste. Such as bitter, dark, etc.). The method may include US 2017/0215631 A1 storing the process profile(s) for the one or more target beverages or processes, as in 2320.)
Regarding claim 8: Studor discloses: The method of claim 1,
Studor further discloses: further comprising: estimating an order pick-up time at the earlier second store; checking a queue at the second individual beverage robot at the earlier second store to determine an estimated completion time for the beverage; determining that the beverage will be completed at least a predetermined amount of time before the order pick-up time; and pausing preparation of the beverage in response to the determination. ([0166] customers may interact with the automated beverage generation systems described herein using customer applications (e.g., applications for the web and/or for Smartphones). In various embodiments. Such applications may perform (or enable the system to provide) any of a variety of scheduling related functions, including any or all of those described below. For example, these applications may allow a customer to choose either the closest kiosk, or their favorite kiosk, as the kiosk to produce their requested beverage(s). The applications may allow a customer to place an order for a single drink or for multiple drinks based on their own ordering history and favorite drinks, or from a menu of drinks available from the selected kiosk. In some embodiments, the applications may, based on GPS distance, routing, and/or traffic congestion information, enable the system to recommend a time and/or a location at which the drink(s) should be prepared and ready for pick up. The applications may allow a customer to select either their favorite time/location, or a time/location that was proposed by the system based on their location and other information (as described above). [0180] if the automated kiosk does not have required ingredients and/or available resources needed to produce a requested beverage at the requested delivery time, the request may be declined, or the customer may be asked for authorization to direct the order to a different kiosk that is able to produce the beverage in the desired timeframe (e.g., if it is a remotely place order). 0181. As illustrated in FIG. 27, the method may include incorporating the accepted requests into a scheduling queue dependent on a requested or target delivery or pick up time for each request (e.g., a delivery or pick up time requested by customer or a target delivery time for a speculative or preemptive order request made by the master controller/ scheduler), as in 2730. The method may include beginning production of a particular beverage in the queue, as in 2740, and advancing production of the particular beverage, as resources are available (as in 2750). As illustrated in this example, a partially completed beverage may be staged between processes until resources are available for the next required step. In some embodiments, progress updates may be provided to the customer as production of the beverage advances. For example, updates may be displayed at the kiosk or provided to the customer remotely (e.g., through a web browser or ordering application on a remote computer or Smartphone). The particular beverage may be presented to the customer when it is completed, or staged at a “will-call area until customer arrives for pick up (or is otherwise available to take deliver of the beverage), as in 2760.)
Regarding claim 9: Studor discloses: The method of claim 8,
Studor further discloses: wherein estimating the order pick-up time comprises: checking a current geographic location of the user based on geographic position signals (GPS) received from a user device associated with the user; and calculating a travel time to the earlier second store based on the current geographic location of the user. ([0166] customers may interact with the automated beverage generation systems described herein using customer applications (e.g., applications for the web and/or for Smartphones). In various embodiments. Such applications may perform (or enable the system to provide) any of a variety of scheduling related functions, including any or all of those described below. For example, these applications may allow a customer to choose either the closest kiosk, or their favorite kiosk, as the kiosk to produce their requested beverage(s). The applications may allow a customer to place an order for a single drink or for multiple drinks based on their own ordering history and favorite drinks, or from a menu of drinks available from the selected kiosk. In some embodiments, the applications may, based on GPS distance, routing, and/or traffic congestion information, enable the system to recommend a time and/or a location at which the drink(s) should be prepared and ready for pick up. The applications may allow a customer to select either their favorite time/location, or a time/location that was proposed by the system based on their location and other information (as described above). [0180] if the automated kiosk does not have required ingredients and/or available resources needed to produce a requested beverage at the requested delivery time, the request may be declined, or the customer may be asked for authorization to direct the order to a different kiosk that is able to produce the beverage in the desired timeframe (e.g., if it is a remotely place order). 0181. As illustrated in FIG. 27, the method may include incorporating the accepted requests into a scheduling queue dependent on a requested or target delivery or pick up time for each request (e.g., a delivery or pick up time requested by customer or a target delivery time for a speculative or preemptive order request made by the master controller/ scheduler), as in 2730. The method may include beginning production of a particular beverage in the queue, as in 2740, and advancing production of the particular beverage, as resources are available (as in 2750). As illustrated in this example, a partially completed beverage may be staged between processes until resources are available for the next required step. In some embodiments, progress updates may be provided to the customer as production of the beverage advances. For example, updates may be displayed at the kiosk or provided to the customer remotely (e.g., through a web browser or ordering application on a remote computer or Smartphone). The particular beverage may be presented to the customer when it is completed, or staged at a “will-call area until customer arrives for pick up (or is otherwise available to take deliver of the beverage), as in 2760.)
Regarding claim 10: Studor discloses: The method of claim 8,
Studor further discloses: wherein estimating the order pick-up time comprises identifying a requested pick-up time in the order. ([0166] customers may interact with the automated beverage generation systems described herein using customer applications (e.g., applications for the web and/or for Smartphones). In various embodiments. Such applications may perform (or enable the system to provide) any of a variety of scheduling related functions, including any or all of those described below. For example, these applications may allow a customer to choose either the closest kiosk, or their favorite kiosk, as the kiosk to produce their requested beverage(s). The applications may allow a customer to place an order for a single drink or for multiple drinks based on their own ordering history and favorite drinks, or from a menu of drinks available from the selected kiosk. In some embodiments, the applications may, based on GPS distance, routing, and/or traffic congestion information, enable the system to recommend a time and/or a location at which the drink(s) should be prepared and ready for pick up. The applications may allow a customer to select either their favorite time/location, or a time/location that was proposed by the system based on their location and other information (as described above). [0180] if the automated kiosk does not have required ingredients and/or available resources needed to produce a requested beverage at the requested delivery time, the request may be declined, or the customer may be asked for authorization to direct the order to a different kiosk that is able to produce the beverage in the desired timeframe (e.g., if it is a remotely place order). 0181. As illustrated in FIG. 27, the method may include incorporating the accepted requests into a scheduling queue dependent on a requested or target delivery or pick up time for each request (e.g., a delivery or pick up time requested by customer or a target delivery time for a speculative or preemptive order request made by the master controller/ scheduler), as in 2730. The method may include beginning production of a particular beverage in the queue, as in 2740, and advancing production of the particular beverage, as resources are available (as in 2750). As illustrated in this example, a partially completed beverage may be staged between processes until resources are available for the next required step. In some embodiments, progress updates may be provided to the customer as production of the beverage advances. For example, updates may be displayed at the kiosk or provided to the customer remotely (e.g., through a web browser or ordering application on a remote computer or Smartphone). The particular beverage may be presented to the customer when it is completed, or staged at a “will-call area until customer arrives for pick up (or is otherwise available to take deliver of the beverage), as in 2760.)
Regarding claim 11: Studor discloses: A method for operating a network of a plurality of beverage robots, the method comprising: receiving an order for a beverage from a first beverage robot from the plurality of beverage robots, wherein the beverage is associated with a recipe requiring one or more ingredients; identifying a subset of beverage robots based on the order, the subset of beverage robots comprising the first beverage robot and one or more second beverage robots able to prepare the beverage based on the one or more ingredients required by the recipe; for each individual beverage robot in the subset of beverage robots, determining an estimated reception time at the individual beverage robot, the estimated reception time associated with a time a user would receive their order from the individual beverage robot; presenting the subset of beverage robots to the user with an indication of the estimated reception time at each of the individual beverage robots; receiving an indication of a selected beverage robot from the subset of beverage robots; and sending the order to the selected beverage robot to cause the order to be prepared by the selected beverage robot. ([0166] customers may interact with the automated beverage generation systems described herein using customer applications (e.g., applications for the web and/or for Smartphones). In various embodiments. Such applications may perform (or enable the system to provide) any of a variety of scheduling related functions, including any or all of those described below. For example, these applications may allow a customer to choose either the closest kiosk, or their favorite kiosk, as the kiosk to produce their requested beverage(s). The applications may allow a customer to place an order for a single drink or for multiple drinks based on their own ordering history and favorite drinks, or from a menu of drinks available from the selected kiosk. In some embodiments, the applications may, based on GPS distance, routing, and/or traffic congestion information, enable the system to recommend a time and/or a location at which the drink(s) should be prepared and ready for pick up. The applications may allow a customer to select either their favorite time/location, or a time/location that was proposed by the system based on their location and other information (as described above). [0180] if the automated kiosk does not have required ingredients and/or available resources needed to produce a requested beverage at the requested delivery time, the request may be declined, or the customer may be asked for authorization to direct the order to a different kiosk that is able to produce the beverage in the desired timeframe (e.g., if it is a remotely place order). 0181. As illustrated in FIG. 27, the method may include incorporating the accepted requests into a scheduling queue dependent on a requested or target delivery or pick up time for each request (e.g., a delivery or pick up time requested by customer or a target delivery time for a speculative or preemptive order request made by the master controller/ scheduler), as in 2730. The method may include beginning production of a particular beverage in the queue, as in 2740, and advancing production of the particular beverage, as resources are available (as in 2750). As illustrated in this example, a partially completed beverage may be staged between processes until resources are available for the next required step. In some embodiments, progress updates may be provided to the customer as production of the beverage advances. For example, updates may be displayed at the kiosk or provided to the customer remotely (e.g., through a web browser or ordering application on a remote computer or Smartphone). The particular beverage may be presented to the customer when it is completed, or staged at a “will-call area until customer arrives for pick up (or is otherwise available to take deliver of the beverage), as in 2760.)
Regarding claim 12: Studor discloses: The method of claim 11,
Studor further discloses: wherein, for each of the individual beverage robots in the subset of beverage robots, determining the estimated reception time comprises checking a queue at the individual beverage robot. ([0166] customers may interact with the automated beverage generation systems described herein using customer applications (e.g., applications for the web and/or for Smartphones). In various embodiments. Such applications may perform (or enable the system to provide) any of a variety of scheduling related functions, including any or all of those described below. For example, these applications may allow a customer to choose either the closest kiosk, or their favorite kiosk, as the kiosk to produce their requested beverage(s). The applications may allow a customer to place an order for a single drink or for multiple drinks based on their own ordering history and favorite drinks, or from a menu of drinks available from the selected kiosk. In some embodiments, the applications may, based on GPS distance, routing, and/or traffic congestion information, enable the system to recommend a time and/or a location at which the drink(s) should be prepared and ready for pick up. The applications may allow a customer to select either their favorite time/location, or a time/location that was proposed by the system based on their location and other information (as described above). [0178] The operations of the scheduled may be further illustrated by the following example scenario. In this example, there are multiple orders queued up, and a cus tomer is working through the touch screen interface to place an order. The scheduler may look at the available resources, and may determine, for example, that one frother is busy, that a second frother is available, and that one cup has had milk dispensed into it and is sitting in the staging area, but it is not yet been frothed. The scheduler may directs the XYZ actuator to pick up the cup with the dispensed milk from the staging area and move it to the second idle frothing module. It may then send a command to that second frothing module to froth the milk to the prescribed temperature. Meanwhile, the first frothing unit that was busy, may issue a communi cation back to the scheduler that the frothing that was in progress is now done. In this example, once the scheduler sees that the first frothing unit has completed frothing, and that the XYZ transporter is free, it may send a command to the XYZ transporter to pick up the cup from the first frother, and (if an espresso resource is available and ready to receive a cup) take the cup to that espresso resource. If no espresso resource is available or ready, then XYZ transporter may be commanded to take the cup to the staging area.)
Regarding claim 13: Studor discloses: The method of claim 11,
Studor further discloses: wherein, for each of the individual beverage robots in the subset of beverage robots, determining the estimated reception time comprises calculating a travel time between a current location of the user and the individual beverage robot. ([0166] customers may interact with the automated beverage generation systems described herein using customer applications (e.g., applications for the web and/or for Smartphones). In various embodiments. Such applications may perform (or enable the system to provide) any of a variety of scheduling related functions, including any or all of those described below. For example, these applications may allow a customer to choose either the closest kiosk, or their favorite kiosk, as the kiosk to produce their requested beverage(s). The applications may allow a customer to place an order for a single drink or for multiple drinks based on their own ordering history and favorite drinks, or from a menu of drinks available from the selected kiosk. In some embodiments, the applications may, based on GPS distance, routing, and/or traffic congestion information, enable the system to recommend a time and/or a location at which the drink(s) should be prepared and ready for pick up. The applications may allow a customer to select either their favorite time/location, or a time/location that was proposed by the system based on their location and other information (as described above). [0180] if the automated kiosk does not have required ingredients and/or available resources needed to produce a requested beverage at the requested delivery time, the request may be declined, or the customer may be asked for authorization to direct the order to a different kiosk that is able to produce the beverage in the desired timeframe (e.g., if it is a remotely place order). 0181. As illustrated in FIG. 27, the method may include incorporating the accepted requests into a scheduling queue dependent on a requested or target delivery or pick up time for each request (e.g., a delivery or pick up time requested by customer or a target delivery time for a speculative or preemptive order request made by the master controller/ scheduler), as in 2730. The method may include beginning production of a particular beverage in the queue, as in 2740, and advancing production of the particular beverage, as resources are available (as in 2750). As illustrated in this example, a partially completed beverage may be staged between processes until resources are available for the next required step. In some embodiments, progress updates may be provided to the customer as production of the beverage advances. For example, updates may be displayed at the kiosk or provided to the customer remotely (e.g., through a web browser or ordering application on a remote computer or Smartphone). The particular beverage may be presented to the customer when it is completed, or staged at a “will-call area until customer arrives for pick up (or is otherwise available to take deliver of the beverage), as in 2760.)
Regarding claim 15: Studor discloses: The method of claim 11,
Studor further discloses: further comprising: estimating an order pick-up time at the selected beverage robot; and queuing the order at the selected beverage robot to be completed a predetermined amount of time before the order pick-up time. ([0006] a system that generates brewed beverages by performing one or more chemical and/or mechanical processes may receive requests to produce specified brewed beverages through any input mechanism of the system, including, but not limited to, an input device that is co-located with the process modules for producing the beverages or an interface mechanism that receives requests made through a remote communication mechanism (e.g., a web interface or Smartphone application). For example, an order for one or more specified beverages may represent a single transaction that includes an expected or requested beverage pick up time, or an order for one or more specified beverages may represent a regular or standing order that includes a pre-determined schedule of two or more times at which the specified brewed beverage(s) will be retrieved. As used herein, the term “brewed bever age' may refer to any beverage produced, at least in part, by an organic extraction process (including, but not limited to, espresso, coffee, tea, or chai), and which may or may not be combined with one or more other ingredients (including, but not limited to, milk, Soy milk, almond milk, flavorings,)
Regarding claim 16: Rejected using the same rationale as claim 1.
Regarding claim 17: Studor discloses: The robotic system of claim 16,
Studor further discloses: wherein the computing system is further configured to: receive, from the second store, an acknowledgment (ACK) notification confirming reception of the order, wherein the ACK notification; and provide, to the user, a confirmation that the second store received the order. ([0166] customers may interact with the automated beverage generation systems described herein using customer applications (e.g., applications for the web and/or for Smartphones). In various embodiments. Such applications may perform (or enable the system to provide) any of a variety of scheduling related functions, including any or all of those described below. For example, these applications may allow a customer to choose either the closest kiosk, or their favorite kiosk, as the kiosk to produce their requested beverage(s). The applications may allow a customer to place an order for a single drink or for multiple drinks based on their own ordering history and favorite drinks, or from a menu of drinks available from the selected kiosk. In some embodiments, the applications may, based on GPS distance, routing, and/or traffic congestion information, enable the system to recommend a time and/or a location at which the drink(s) should be prepared and ready for pick up. The applications may allow a customer to select either their favorite time/location, or a time/location that was proposed by the system based on their location and other information (as described above). [0180] if the automated kiosk does not have required ingredients and/or available resources needed to produce a requested beverage at the requested delivery time, the request may be declined, or the customer may be asked for authorization to direct the order to a different kiosk that is able to produce the beverage in the desired timeframe (e.g., if it is a remotely place order). 0181. As illustrated in FIG. 27, the method may include incorporating the accepted requests into a scheduling queue dependent on a requested or target delivery or pick up time for each request (e.g., a delivery or pick up time requested by customer or a target delivery time for a speculative or preemptive order request made by the master controller/ scheduler), as in 2730. The method may include beginning production of a particular beverage in the queue, as in 2740, and advancing production of the particular beverage, as resources are available (as in 2750). As illustrated in this example, a partially completed beverage may be staged between processes until resources are available for the next required step. In some embodiments, progress updates may be provided to the customer as production of the beverage advances. For example, updates may be displayed at the kiosk or provided to the customer remotely (e.g., through a web browser or ordering application on a remote computer or Smartphone). The particular beverage may be presented to the customer when it is completed, or staged at a “will-call area until customer arrives for pick up (or is otherwise available to take deliver of the beverage), as in 2760.)
Regarding claim 18: Studor discloses: The robotic system of claim 16,
Studor further discloses: wherein identifying that the user can receive the one or more beverages in the order from the second beverage robot at the earlier time than from the first beverage robot comprises: determining a first reception time from the first beverage robot, wherein determining the first reception time includes: calculating a first time of arrival based on a first travel time between a current location of the user and the first store; checking a first queue at the first beverage robot, wherein the first queue is associated with a number of beverages already assigned to be prepared by the first beverage robot ahead of the one or more beverages in the order; determining a first estimated completion time for each of the one or more beverages in the order; and identifying the first reception time based on which of the first time of arrival and the first estimated completion time is later; and determining a second reception time from the second beverage robot, wherein determining the second reception time includes: calculating a second time of arrival based on a second travel time between the current location of the user and the second store; checking a second queue at the second beverage robot, wherein the second queue is associated with a number of beverages already assigned to be prepared by the second beverage robot ahead of the one or more beverages in the order; determining a second estimated completion time for each of the one or more beverages in the order; and identifying the second reception time based on which of the second time of arrival and the second estimated completion time is later. ([0166] customers may interact with the automated beverage generation systems described herein using customer applications (e.g., applications for the web and/or for Smartphones). In various embodiments. Such applications may perform (or enable the system to provide) any of a variety of scheduling related functions, including any or all of those described below. For example, these applications may allow a customer to choose either the closest kiosk, or their favorite kiosk, as the kiosk to produce their requested beverage(s). The applications may allow a customer to place an order for a single drink or for multiple drinks based on their own ordering history and favorite drinks, or from a menu of drinks available from the selected kiosk. In some embodiments, the applications may, based on GPS distance, routing, and/or traffic congestion information, enable the system to recommend a time and/or a location at which the drink(s) should be prepared and ready for pick up. The applications may allow a customer to select either their favorite time/location, or a time/location that was proposed by the system based on their location and other information (as described above). [0180] if the automated kiosk does not have required ingredients and/or available resources needed to produce a requested beverage at the requested delivery time, the request may be declined, or the customer may be asked for authorization to direct the order to a different kiosk that is able to produce the beverage in the desired timeframe (e.g., if it is a remotely place order). 0181. As illustrated in FIG. 27, the method may include incorporating the accepted requests into a scheduling queue dependent on a requested or target delivery or pick up time for each request (e.g., a delivery or pick up time requested by customer or a target delivery time for a speculative or preemptive order request made by the master controller/ scheduler), as in 2730. The method may include beginning production of a particular beverage in the queue, as in 2740, and advancing production of the particular beverage, as resources are available (as in 2750). As illustrated in this example, a partially completed beverage may be staged between processes until resources are available for the next required step. In some embodiments, progress updates may be provided to the customer as production of the beverage advances. For example, updates may be displayed at the kiosk or provided to the customer remotely (e.g., through a web browser or ordering application on a remote computer or Smartphone). The particular beverage may be presented to the customer when it is completed, or staged at a “will-call area until customer arrives for pick up (or is otherwise available to take deliver of the beverage), as in 2760.)
Regarding claim 20: Studor discloses: The robotic system of claim 16,
Studor further discloses: wherein the computing system is further configured to: check whether an estimated time of arrival for the user at the second store is in sync with an estimated completion time for the one or more beverages in the order; and in response to a determination that the estimated time of arrival is not in sync with the estimated completion time, send a message to the second beverage robot causing the second beverage robot to pause the preparation of the one or more beverages using the adjusted recipe. ([0166] customers may interact with the automated beverage generation systems described herein using customer applications (e.g., applications for the web and/or for Smartphones). In various embodiments. Such applications may perform (or enable the system to provide) any of a variety of scheduling related functions, including any or all of those described below. For example, these applications may allow a customer to choose either the closest kiosk, or their favorite kiosk, as the kiosk to produce their requested beverage(s). The applications may allow a customer to place an order for a single drink or for multiple drinks based on their own ordering history and favorite drinks, or from a menu of drinks available from the selected kiosk. In some embodiments, the applications may, based on GPS distance, routing, and/or traffic congestion information, enable the system to recommend a time and/or a location at which the drink(s) should be prepared and ready for pick up. The applications may allow a customer to select either their favorite time/location, or a time/location that was proposed by the system based on their location and other information (as described above). [0180] if the automated kiosk does not have required ingredients and/or available resources needed to produce a requested beverage at the requested delivery time, the request may be declined, or the customer may be asked for authorization to direct the order to a different kiosk that is able to produce the beverage in the desired timeframe (e.g., if it is a remotely place order). 0181. As illustrated in FIG. 27, the method may include incorporating the accepted requests into a scheduling queue dependent on a requested or target delivery or pick up time for each request (e.g., a delivery or pick up time requested by customer or a target delivery time for a speculative or preemptive order request made by the master controller/ scheduler), as in 2730. The method may include beginning production of a particular beverage in the queue, as in 2740, and advancing production of the particular beverage, as resources are available (as in 2750). As illustrated in this example, a partially completed beverage may be staged between processes until resources are available for the next required step. In some embodiments, progress updates may be provided to the customer as production of the beverage advances. For example, updates may be displayed at the kiosk or provided to the customer remotely (e.g., through a web browser or ordering application on a remote computer or Smartphone). The particular beverage may be presented to the customer when it is completed, or staged at a “will-call area until customer arrives for pick up (or is otherwise available to take deliver of the beverage), as in 2760.)
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ATTICUS A CAMERON whose telephone number is 703-756-4535. The examiner can normally be reached M-F 8:30 am - 4:30 pm. 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, Thomas Worden can be reached on 571-272-4876. 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.
/ATTICUS A CAMERON/ /JASON HOLLOWAY/ Primary Examiner, Art Unit 3658 Examiner, Art Unit 3658A
Prosecution Insights