DETAILED ACTION
This action is in reply to the claims filed on 01/12/2026.
Claims 1-20 are rejected.
Claims 1-20 are currently pending and have been examined.
Response to Amendment
Applicant’s claims, filed 01/12/2026, have been entered.
Drawing Objections
The drawing objections from the prior Office Action have been withdrawn pursuant Applicant’s submission of a new specification paragraphs.
Priority
The current Application claims priority from Provisional Application No. 63/412,686 filed 10/03/2022. Therefore, the instant claims receive the effective filing date of 10/03/2022.
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 .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Under Step 1 of the Subject Matter Eligibility Test for Products and Processes, the claims must be directed to one of the four statutory categories (see MPEP 2106.03). All the claims are directed to one of the four statutory categories (YES).
Under Step 2A of the Subject Matter Eligibility Test, it is determined whether the claims are directed to a judicially recognized exception (see MPEP 2106.04). Step 2A is a two-prong inquiry.
Under Prong 1, it is determined whether the claim recites a judicial exception (YES). Taking Claim 1 as representative, the claim recites limitations that fall within the certain methods of organizing human activity groupings of abstract ideas, including:
-A system for processing orders for food through a network processor and transmitting the orders for food to a courier, the system comprising:
-a customer processor at a customer location configured to transmit[ting] a food order through the network processor;
-a delivery service processor at a delivery service location configured to receive the food order and transmit the food order to a merchant processor at a merchant location, wherein the merchant processor is configured to process[es] the food order and transmit[s[ a signal to the delivery service processor accepting or declining the food order; and
-a virtual assistant device at a courier location, the virtual assistant device being communicatively coupled to a mobile device of the courier, wherein the virtual assistant device is configured to receive[s] food order data, process[es] the food order data, and produce[s] recommendations based on the food order data, with the recommendations being at least audibly broadcast to the courier
The above limitations recite the concept of processing food orders and providing recommendations to couriers regarding the food orders. The above limitations fall within the “Certain Methods of Organizing Human Activity” groupings of abstract ideas, enumerated in MPEP 2106.04(a).
Certain methods of organizing human activity include:
fundamental economic principles or practices (including hedging, insurance, and mitigating risk)
commercial or legal interactions (including agreements in the form of contracts; legal obligations; advertising, marketing or sales activities or behaviors; and business relations)
managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instructions)
The limitations of a system for processing orders for food through a network processor and transmitting the orders for food to a courier, the system comprising: a customer processor at a customer location configured to transmit[ting] a food order through the network processor; a delivery service processor at a delivery service location configured to receive the food order and transmit the food order to a merchant processor at a merchant location, wherein the merchant processor is configured to process[es] the food order and transmit[s[ a signal to the delivery service processor accepting or declining the food order; and a virtual assistant device at a courier location, the virtual assistant device being communicatively coupled to a mobile device of the courier, wherein the virtual assistant device is configured to receive[s] food order data, process[es] the food order data, and produce[s] recommendations based on the food order data, with the recommendations being at least audibly broadcast to the courier are processes that, under their broadest reasonable interpretation, cover a commercial interaction. That is, other than reciting that processing the orders is through a network, that the customer is a customer processor, that the transmitting is through the network processor, that the delivery service is a delivery service processor, that the merchant is a merchant processor, that the processing of the food order and transmitting of the signal is by the merchant processor, that the signal is to the delivery service processor, that the assistant is a virtual assistant device, that the virtual assistant device being communicatively coupled to a mobile device of the courier, and that the receiving, processing, and producing of recommendations is by the virtual assistant device, nothing in the claim element precludes the step from practically being performed by people. For example, but for the “network processor,” “customer processor,” “configured to,” “delivery service processor,” “merchant processor,” “virtual assistant device,” and “the virtual assistant device being communicatively coupled to a mobile device,” language, “transmitting,” “receive,” “transmit,” “process,” “transmit,” “receive,” “process,” and “produce recommendations” in the context of this claim encompasses advertising, and marketing or sales activities.
Under Prong 2, it is determined whether the claim recites additional elements that integrate the exception into a practical application of the exception. This judicial exception is not integrated into a practical application (NO).
-A system for processing orders for food through a network processor and transmitting the orders for food to a courier, the system comprising:
-a customer processor at a customer location configured to transmit a food order through the network processor;
-a delivery service processor at a delivery service location configured to receive the food order and transmit the food order to a merchant processor at a merchant location, wherein the merchant processor is configured to process the food order and transmit a signal to the delivery service processor accepting or declining the food order; and
-a virtual assistant device at a courier location, the virtual assistant device being communicatively coupled to a mobile device of the courier, wherein the virtual assistant device is configured to receive food order data, process the food order data, and produce recommendations based on the food order data, with the recommendations being at least audibly broadcast to the courier
These limitations are not indicative of integration into a practical application because:
The additional elements of claim 1 are recited at a high level of generality (i.e. as generic computing hardware) such that they amount to nothing more than mere instructions to implement or apply the abstract idea on a generic computing hardware (or, merely use a computer as a tool to perform an abstract idea). Specifically, the additional elements of a network processor, a customer processor, a delivery service processor, a merchant processor, a virtual assistant device, and the virtual assistant device being communicatively coupled to a mobile device, are recited at a high-level of generality (i.e. as a generic processor performing the generic computer functions of transmitting data, receiving data, processing data, and producing recommendations) such that they amount do no more than mere instructions to apply the exception using generic computer components. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea. Further, the additional elements do no more than generally link the use of the judicial exception to a particular technological environment or field of use (such as computers or computing networks). Employing well-known computer functions to execute an abstract idea, even when limiting the use of the idea to one particular environment, does not integrate the exception into a practical application.
Additionally, the additional elements are insufficient to integrate the abstract idea into a practical application because the claim fails to i) reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, ii) apply the judicial exception with, or use the judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim, iii) effect a transformation or reduction of a particular article to a different state or thing, or iv) apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Accordingly, the judicial exception is not integrated into a practical application.
Under Step 2B, it is determined whether the claims recite additional elements that amount to significantly more than the judicial exception. The claims of the present application do not include additional elements that are sufficient to amount to significantly more than the judicial exception (NO).
In the case of claim 1, taken individually or as a whole, the additional elements of claim 9 do not provide an inventive concept. As discussed above under step 2A (prong 2) with respect to the integration of the abstract idea into a practical application, the additional elements used to perform the claimed functions amount to no more than a general link to a technological environment.
Even considered as an ordered combination (as a whole), the additional elements do not add anything significantly more than when considered individually.
Claim 19 is a method reciting similar functions as claim 1. Examiner notes that claim 19 recites the additional elements of a network processor, a customer processor, a delivery service processor, a merchant processor, and a virtual assistant device, however, claim 19 does not qualify as eligible subject matter for similar reasons as claim 1 indicated above.
Therefore, claims 1 and 19 do not provide an inventive concept and do not qualify as eligible subject matter.
Dependent claims 2-18 and 20, when analyzed as a whole, are held to be patent ineligible under 35 U.S.C. § 101 because they do not add “significantly more” to the abstract idea. More specifically, dependent claims 2-18 and 20 further fall within the “Certain Methods of Organizing Human Activity” grouping of abstract ideas in that they recite commercial interactions. Dependent claims 3 and 17-18 do not recite any farther additional elements, and as such are not indicative of integration into a practical application for at least similar reasons discussed above. Dependent claims 2, 4-16, and 20 recite the additional elements of the virtual assistant device, a speaker, a microphone, a separate physical device, the mobile device, a display, a touch screen component, a power source, electrical energy, a wireless adapter, wireless technology, a transmission adapter, the customer processor, the delivery service processor, and the merchant processor, a software component, autonomously, and an electric communication, but similar to the analysis under prong two of Step 2A these additional elements are used as a tool to perform the abstract idea. As such, under prong two of Step 2A, claims 2-18 and 20 are not indicative of integration into a practical application for at least similar reasons as discussed above. Thus, dependent claims 2-18 and 20 are “directed to” an abstract idea. Next, under Step 2B, similar to the analysis of claims 1 and 19, dependent claims 2-18 and 20 when analyzed individually and as an ordered combination, merely further define the commonplace business method (i.e. processing food orders and providing recommendations to couriers regarding the food orders) being applied on a general-purpose computer and, therefore, do not amount to significantly more than the abstract idea itself. Accordingly, the Examiner concludes that there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself. The analysis above applies to all statutory categories of invention.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-15 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Dhesi et al. (US 2021/0019694 A1), hereinafter Dhesi, in view of Swift et al. (US 2019/0102146 A1) hereinafter Swift.
Regarding claim 1, Dhesi discloses a system for processing orders for food through a network processor and transmitting the orders for food to a courier, the system comprising:
-a customer processor at a customer location configured to transmit a food order through the network processor (Dhesi, see at least: “The client device 10 may transmit this order [i.e. a customer processor at a customer location configured to transmit a food order] to a fulfillment engine 20. In an exemplary embodiment, fulfillment engine 20 is managed, operated, or facilitated (and/or in some embodiments, owned) by a service provider” [0042] and “Client 12, via device 10, may send one or more orders 201-1 to a fulfillment engine 20. An order may include information such as the number of meals to deliver [i.e. a food order]” [0052] and “Client device 10 may be, for instance, a mobile device such as smart phone, tablet, computer, laptop, or other electronic device that can communicate via a network (not specifically shown) [i.e. through a network processor]” [0040]);
-a delivery service processor at a delivery service location configured to receive the food order and transmit the food order to a merchant processor at a merchant location, wherein the merchant processor is configured to process the food order and transmit a signal to the delivery service processor accepting or declining the food order (Dhesi, see at least: “Fulfillment engine 20 transmits and/or receives order data [i.e. a delivery service processor at a delivery service location configured to receive the food order], profile/preference data, fulfillment data, and/or feedback data, etc. to/from one or more of merchant devices 30 [i.e. and transmit the food order to a merchant processor at a merchant location] and customer devices 10 (such transmissions shown in FIG. 1A with solid lines). These types of data transmission are performed over a communication network (not specifically shown) [i.e. through the network processor]” [0047] and “At step 325 the order (or information about the order, such as the order items, destination, and/or delivery date/time) is sent to the merchant 32. At step 330, the most optimal merchant 30 receives the order. Step 332 involves a decision by the merchant as to whether it accepts the order [i.e. wherein the merchant processor is configured to process the food order]. In some embodiments, the merchant 32 is under contract to be able to produce a certain number of items for the fulfillment engine 20. In this case, the merchant 32 would only reply to the fulfillment engine 20 with a confirmation message (Yes, in response to step 332) [i.e. and transmit a signal to the delivery service processor accepting or declining the food order]” [0078]); and
-a courier device at a courier location, the courier device being a mobile device of the courier, wherein the courier device is configured to receive food order data and process the food order data (Dhesi, see at least: “FIG. 1A further illustrates one or more courier systems 42, each using at least one courier device 40, which may be, for instance, a smart phone [i.e. a courier device at a courier location, the courier device being a mobile device of the courier], tablet, computer, laptop, or other electronic device that can communicate with the fulfillment engine via a network (not specifically shown)” [0045] and “a merchant has confirmed acceptance of the order but does not provide its own delivery, therefore, control passes to Step 335 to send an order to an optimal courier (step 340) for delivery of the order. Other configurations may be possible in other embodiments, for example, where the merchant provides delivery fulfillment and no third party courier is needed. The courier may also determine its availability to fulfill the order at step 342 [i.e. wherein the courier device is configured to receive food order data and process the food order data], and if not available (No in step 342), the process cycles back to step 320 and the order is transmitted to the next most optimal courier (or in some cases, the next most optimal merchant if no courier is available). If the courier confirms available (Yes in step 342), the process continues to step 345” [0080] and Fig. 3).
Dhesi does not explicitly disclose a virtual assistant device at a courier location, the virtual assistant device being communicatively coupled to a mobile device of the courier, wherein the virtual assistant device is configured to receive food order data, process the food order data, and produce recommendations based on the food order data, with the recommendations being at least audibly broadcast to the courier.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known techniques of a virtual assistant device at a courier location, the virtual assistant device being communicatively coupled to a mobile device of the courier (Swift, see at least: “the list of offers, services, and/or other information (e.g., sales information for the customer or competitors of the customer) may be presented audibly to the delivery driver through a speaker of the mobile device and/or the vehicle communication device [i.e. a virtual assistant device at a courier location]” [0052] and “the server 160 can communicate with one or more user devices 110A-110N via a network 120 [i.e. the virtual assistant device being communicatively coupled to]” [0058] and “User devices 110A-110N and/or server 160 may each be implemented as a computing device, such as a personal computer and/or other networked device, such as a cellular phone, tablet computer, mobile device [i.e. the virtual assistant device being communicatively coupled to a mobile device of the courier], point of sale terminal, inventory management terminal, vehicle communication system etc.” [0059] and Fig. 1),
wherein the virtual assistant device is configured to receive order data, process the order data, and produce recommendations based on the order data, with the recommendations being at least audibly broadcast to the courier (Swift, see at least: “an apparatus, such as a mobile device carried by a delivery driver and/or a vehicle communication device, may receive a first voice command from the delivery driver requesting information from the apparatus. The apparatus may process the first voice command and determine a first set of information to present to the delivery driver. The determination of a first set of information may include processing by the apparatus and/or a back-end server. The points of interest may include various topics such as training, sales, routing information, next stop information, remaining stops information, surveys, suggestions for sales/products, new product information, pricing information, and messages for the delivery driver. The set of information may then be more specific information (“items of information”) such as certain training modules, tips, sales performance, next stop information (e.g., products to be delivered and how many, special requirements/procedures/interests of the next stop) [i.e. wherein the virtual assistant device is configured to receive order data]” [0049] and “the list of offers, services, and/or other information (e.g., sales information for the customer or competitors of the customer) may be presented audibly to the delivery driver through a speaker of the mobile device and/or the vehicle communication device [i.e. with the recommendations being at least audibly broadcast to the courier]. In response, the mobile device and/or the vehicle communication device may receive a second voice command from the delivery driver. By way of an example, the second voice command may include a response, such as “Accept,” “Reject,” “Next”, to accept or reject one or more offers, services, and/or information from the presented list. The response may be received via a microphone of the mobile device and/or the vehicle communication device. In response, the mobile device, the vehicle communication device, and/or server may modify the presented list and curate a final set of information to be presented to the delivery driver. For instance, the apparatus and/or back-end system may contain sales history, sales in the region (what is selling in nearby locations with similar demographics, and using algorithms make suggestions. For example, the final set of information may include one or more offers, services, and/or other information accepted by the delivery driver as being relevant to the customer at the next delivery location [i.e. process the order data, and produce recommendations based on the order data]” [0052] and see also [0007]). These known techniques are applicable to the system of Dhesi as they both share characteristics and capabilities, namely, they are directed to delivering items from a store.
It would have been recognized that applying the known techniques of a virtual assistant device at a courier location, the virtual assistant device being communicatively coupled to a mobile device of the courier, wherein the virtual assistant device is configured to receive order data, process the order data, and produce recommendations based on the order data, with the recommendations being at least audibly broadcast to the courier, as taught by Swift, to the teachings of Dhesi would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such references into similar systems. Further, adding the modifications of a virtual assistant device at a courier location, the virtual assistant device being communicatively coupled to a mobile device of the courier, wherein the virtual assistant device is configured to receive order data, process the order data, and produce recommendations based on the order data, with the recommendations being at least audibly broadcast to the courier, as taught by Swift, into the system of Dhesi would have been recognized by those of ordinary skill in the art as resulting in an improved system that would utilize dead-time between stops effectively and adhering to safety requirements (Swift, [0049]).
Regarding claim 2, Dhesi in view of Swift teaches the system of claim 1.
Dhesi does not explicitly disclose the virtual assistant device including a speaker for audibly broadcasting information to the courier.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known technique of the virtual assistant device including a speaker for audibly broadcasting information to the courier (Swift, see at least: “the list of offers, services, and/or other information (e.g., sales information for the customer or competitors of the customer) may be presented audibly to the delivery driver through a speaker of the mobile device and/or the vehicle communication device [i.e. wherein the virtual assistant device includes a speaker for audibly broadcasting information to the courier]” [0052]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi with Swift for the reasons identified above with respect to claim 1.
Regarding claim 3, Dhesi in view of Swift teaches the system of claim 2.
Dhesi does not explicitly disclose the audible broadcasting of information comprising verbally broadcasting information to the courier while the courier drives a vehicle.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known technique of the audible broadcasting of information comprising verbally broadcasting information to the courier while the courier drives a vehicle (Swift, see at least: “the list of offers, services, and/or other information (e.g., sales information for the customer or competitors of the customer) may be presented audibly to the delivery driver through a speaker of the mobile device and/or the vehicle communication device [i.e. wherein the audible broadcasting of information comprises verbally broadcasting information to the courier]” [0052] and “While driving, the user or delivery driver may be prevented from accessing and using the interface or screen. The device may impose a “screen lock condition” on the device such that the driver is prevented from accessing and interacting with the visual display. Thus, instead of visually displaying sets of information to the driver, while driving, the device interacts with the driver solely by voice [i.e. wherein the audible broadcasting of information comprises verbally broadcasting information to the courier while the courier drives a vehicle]” [0050]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi with Swift for the reasons identified above with respect to claim 1.
.
Regarding claim 4, Dhesi in view of Swift teaches the system of claim 1.
Dhesi does not explicitly disclose the virtual assistant device including a microphone for receiving verbal inputs from the courier while the courier drives a vehicle.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known technique of the virtual assistant device including a microphone for receiving verbal inputs from the courier while the courier drives a vehicle (Swift, see at least: “the first voice command may have been received via a microphone from the user [i.e. wherein the virtual assistant device includes a microphone for receiving verbal inputs from the courier], and in some embodiments, the first set of information may have been transmitted to the user via a speaker” [0019] and “While driving, the user or delivery driver may be prevented from accessing and using the interface or screen. The device may impose a “screen lock condition” on the device such that the driver is prevented from accessing and interacting with the visual display. Thus, instead of visually displaying sets of information to the driver, while driving, the device interacts with the driver solely by voice [i.e. receiving verbal inputs from the courier while the courier drives a vehicle]” [0050]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi with Swift for the reasons identified above with respect to claim 1.
Regarding claim 5, Dhesi in view of Swift teaches the system of claim 1.
Dhesi does not explicitly disclose the virtual assistant device being a separate physical device from the mobile device of the courier, and the virtual assistant device being positioned within proximity of the mobile device of the courier
Swift, however, teaches delivering items from a store (i.e. abstract), including the known technique of the virtual assistant device being a separate physical device from the mobile device of the courier, and the virtual assistant device being positioned within proximity of the mobile device of the courier (Swift, see at least: “an apparatus, such as a mobile device carried by a delivery driver and/or a vehicle communication device [i.e. wherein the virtual assistant device is a separate physical device from the mobile device of the courier], may receive a first voice command from the delivery driver requesting information from the apparatus” [0049] and “the final set of information may be visually displayed, on the mobile device and/or the vehicle communication device, to the delivery driver when the delivery driver has arrived at a desired location [i.e. and the virtual assistant device is positioned within proximity of the mobile device of the courier] and/or it is determined that no screen lock condition is present” [0052] Examiner notes that both the mobile device and the vehicle communication device would be in the courier’s vehicle). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi with Swift for the reasons identified above with respect to claim 1.
Regarding claim 6, Dhesi in view of Swift teaches the system of claim 5.
Dhesi does not explicitly disclose the virtual assistant device comprising: a microphone configured to receive verbal inputs from the courier; a speaker configured to audibly broadcast information to the courier; a display configured to display graphics, wherein the display includes a touch screen component configured for entering data and controlling the virtual assistant device; and a power source for providing electrical energy to the virtual assistant device.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known techniques of the virtual assistant device comprising:
a microphone configured to receive verbal inputs from the courier (Swift, see at least: “the first voice command may have been received via a microphone from the user [i.e. wherein the virtual assistant device comprises: a microphone configured to receive verbal inputs from the courier], and in some embodiments, the first set of information may have been transmitted to the user via a speaker” [0019]);
a speaker configured to audibly broadcast information to the courier (Swift, see at least: “the list of offers, services, and/or other information (e.g., sales information for the customer or competitors of the customer) may be presented audibly to the delivery driver through a speaker of the mobile device and/or the vehicle communication device [i.e. wherein the virtual assistant device comprises: a speaker configured to audibly broadcast information to the courier]” [0052]);
a display configured to display graphics, wherein the display includes a touch screen component configured for entering data and controlling the virtual assistant device (Swift, see at least: “the delivery drivers often carry a communication device, such as, a mobile device, and/or the delivery vehicle may have an in-built communication interface, to enable the delivery drivers to communicate with a server, workflow management system, warehouse, store managers, other delivery drivers, and the like” [0048] and “The user devices 110A-110N and/or server 160 may include one or more input devices, including but not limited to a keyboard, a number pad, a mouse, a touch-sensitive display [i.e. a display configured to display graphics, wherein the display includes a touch screen component], a navigation key, a function key, a microphone, a voice recognition component, any other mechanism capable of receiving an input from a user [i.e. configured for entering data and controlling the virtual assistant device], or any combination thereof” [0086]); and
a power source for providing electrical energy to the virtual assistant device (Swift, see at least: “the user device 500 is a headset that includes a wireless enabled voice recognition device that utilizes a hands-free profile. As noted above, in some embodiments, the user device, including one or more microphones and one or more speakers as well as one or more of the components further described below, may be a vehicle communication device integrated and/or attached to the vehicle [i.e. to the virtual assistant device]” [0088] and “the electronics module 502 can be used to offload several components of the headset 503 to reduce the weight of the headset 503. In some embodiments, one or more of a rechargeable or long life battery [i.e. a power source for providing electrical energy], display, keypad, Bluetooth® antenna, and printed circuit board assembly (PCBA) electronics can be included in the electronics module 502 and/or otherwise incorporated into the user device 500” [0091]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi with Swift for the reasons identified above with respect to claim 1.
Regarding claim 7, Dhesi in view of Swift teaches the system of claim 6.
Dhesi does not explicitly disclose the touch screen of the display being at least partially disabled when the courier and the virtual assistant device are in motion.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known technique of the touch screen of the display being at least partially disabled when the courier and the virtual assistant device are in motion (Swift, see at least: “the screen lock condition may be activated by locking an interface available to the user to avoid visual display [i.e. wherein the touch screen of the display is at least partially disabled] of a set of information in response to determining that the user is in transit to the desired location [i.e. when the courier and the virtual assistant device are in motion]” [0015]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi with Swift for the reasons identified above with respect to claim 1.
Regarding claim 8, Dhesi in view of Swift teaches the system of claim 1.
Dhesi does not explicitly disclose the virtual assistant device comprising a wireless adapter for communicatively coupling the virtual assistant device to the mobile device of the courier through wireless technology.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known technique of the virtual assistant device comprising a wireless adapter for communicatively coupling the virtual assistant device to the mobile device of the courier through wireless technology (Swift, see at least: “the server 160 can communicate with one or more user devices 110A-110N via a network 120. In this regard, network 120 may include any wired or wireless communication network … In some embodiments, Bluetooth may be used to communicate between devices [i.e. wherein the virtual assistant device comprises a wireless adapter for communicatively coupling the virtual assistant device to the mobile device of the courier through wireless technology]” [0058] and “User devices 110A-110N and/or server 160 may each be implemented as a computing device, such as a personal computer and/or other networked device, such as a cellular phone, tablet computer, mobile device, point of sale terminal, inventory management terminal, vehicle communication system etc. [i.e. coupling the virtual assistant device to the mobile device of the courier], that may be used for any suitable purpose in addition to presenting the interface to facilitate buying items and/or offering items for sale” [0059]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi with Swift for the reasons identified above with respect to claim 1.
Regarding claim 9, Dhesi in view of Swift teaches the system of claim 1. Dhesi further discloses:
-wherein the courier device comprises a transmission adapter configured to communicatively couple with the customer processor, the delivery service processor, and the merchant processor for sending and receiving data (Dhesi, see at least: “one or more courier systems 42, each using at least one courier device 40, which may be, for instance, a smart phone, tablet, computer, laptop, or other electronic device that can communicate with the fulfillment engine via a network [i.e. wherein the courier device comprises a transmission adapter]” [0045] and “Fulfillment engine 20 transmits and/or receives order data, profile/preference data, fulfillment data, and/or feedback data, etc. to/from one or more of merchant devices 30 and customer devices 10 [i.e. configured to communicatively couple with the customer processor, the delivery service processor, and the merchant processor for sending and receiving data] (such transmissions shown in FIG. 1A with solid lines). These types of data transmission are performed over a communication network (not specifically shown). The communication network may comprise one or more network types, such as a wide area network (such as the Internet), a local area network (such an intranet), a cellular network or another type of wireless network, such as Wi-Fi, Bluetooth, Bluetooth Low Energy, and/or other close-range wireless communications, a wired network, such as fiber optics and Ethernet, or any other such network, or any combination thereof” [0047]).
Dhesi does not explicitly disclose the courier device being a virtual assistant device.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known technique of the courier device being a virtual assistant device (Swift, see at least: “the list of offers, services, and/or other information (e.g., sales information for the customer or competitors of the customer) may be presented audibly to the delivery driver through a speaker of the mobile device and/or the vehicle communication device [i.e. the courier device being a virtual assistant device]. In response, the mobile device and/or the vehicle communication device may receive a second voice command from the delivery driver” [0052]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi with Swift for the reasons identified above with respect to claim 1.
Regarding claim 10, Dhesi in view of Swift teaches the system of claim 1.
Dhesi does not explicitly disclose the virtual assistant device being a software component deployed on or within the mobile device of the courier.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known technique of the virtual assistant device being a software component deployed on or within the mobile device of the courier (Swift, see at least: “The user device 110A-110N may parse and process the voice command and transform the voice command into a text request [i.e. wherein the virtual assistant device] for the user device 110A-110N to process and/or for a server 160 to process” [0056] and “the delivery drivers often carry a communication device, such as, a mobile device [i.e. deployed on or within the mobile device of the courier], and/or the delivery vehicle may have an in-built communication interface, to enable the delivery drivers to communicate with a server, workflow management system, warehouse, store managers, other delivery drivers, and the like” [0048] and “the user device may provide hands-free voice communication between the user and the user device. To that end, digital information may be converted to an audio format, and vice versa, to provide speech communication between the user device or an associated system and the user. In an example embodiment, the user device may contain digital instructions or receive digital instructions [i.e. the virtual assistant device is a software component deployed on or within the mobile device of the courier] from a central computer and/or a server and may convert those instructions to audio to be heard by the user. The user may then reply, in a spoken language, and the audio reply or the speech input may be converted to a useable digital format to be transferred back to the central computer and/or the server” [0102]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi with Swift for the reasons identified above with respect to claim 1.
Regarding claim 11, Dhesi in view of Swift teaches the system of claim 1.
Dhesi does not explicitly disclose the virtual assistant courier device being further configured to process and announce navigational direction relating to the merchant location and the customer location.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known technique of the virtual assistant courier device being further configured to process and announce navigational direction relating to the merchant location and the customer location (Swift, see at least: “For example, an apparatus, such as a mobile device carried by a delivery driver and/or a vehicle communication device, may receive a first voice command from the delivery driver requesting information from the apparatus. The apparatus may process the first voice command and determine a first set of information to present to the delivery driver … The points of interest may include various topics such as training, sales, routing information [i.e. wherein the virtual assistant courier device is further configured to process and announce navigational direction], next stop information, remaining stops information, surveys, suggestions for sales/products, new product information, pricing information, and messages for the delivery driver” [0049] and “the first set of information may be transmitted through a speaker (e.g., speaker 505, 708 of a user device 500, 700) [i.e. wherein the virtual assistant courier device is further configured to process and announce navigational direction]” [0124] and “a current location of the user device may be determined by a sensor in the user device 110A-110N, such as, a ground imaging sensor, an electro-optic sensor, a GPS receiver, and the like. The desired location may be obtained from a per-determined delivery schedule, a server, a database, and the like. In an embodiment, the user device may determine a travel route, from a server, for example, for the user device based on the current location, and may determine a desired location [i.e. navigational direction relating to the merchant location and the customer location] based on the travel route. The location data of the user device may then be monitored and/or tracked to determine if the user device is moving along the travel route towards the desired location” [0121]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi with Swift for the reasons identified above with respect to claim 1.
Regarding claim 12, Dhesi in view of Swift teaches the system of claim 1.
Dhesi does not explicitly disclose the virtual assistant device being further configured autonomously, or upon verbal command from the courier, communicate with the delivery service processor, the merchant processor, or the customer processor to provide or request additional data or information.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known technique of the virtual assistant device being further configured autonomously, or upon verbal command from the courier, communicate with the delivery service processor, the merchant processor, or the customer processor to provide or request additional data or information (Swift, see at least: “the method may further include transmitting the first set of information based on the first voice command through speech and in response to receiving a second voice command from the user, such that the second voice command interacts with the first set of information, processing the second voice command to determine a final set of information to transmit to the user [i.e. wherein the virtual assistant device is further configured autonomously, or upon verbal command from the courier] … the list of offers, services, and/or other information (e.g., sales information for the customer or competitors of the customer) may be presented audibly to the delivery driver through a speaker of the mobile device and/or the vehicle communication device. In response, the mobile device and/or the vehicle communication device may receive a second voice command from the delivery driver. By way of an example, the second voice command may include a response, such as “Accept,” “Reject,” “Next”, to accept or reject one or more offers, services, and/or information from the presented list. The response may be received via a microphone of the mobile device and/or the vehicle communication device. In response, the mobile device, the vehicle communication device, and/or server may modify the presented list and curate a final set of information to be presented to the delivery driver. For instance, the apparatus and/or back-end system [i.e. communicate with the delivery service processor] may contain sales history, sales in the region (what is selling in nearby locations with similar demographics, and using algorithms make suggestions. For example, the final set of information may include one or more offers, services, and/or other information accepted by the delivery driver as being relevant to the customer at the next delivery location [i.e. communicate with the delivery service processor, the merchant processor, or the customer processor to provide or request additional data or information]” [0052]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi with Swift for the reasons identified above with respect to claim 1.
Regarding claim 13, Dhesi in view of Swift teaches the system of claim 12.
Dhesi does not explicitly disclose that the communication by the virtual assistant device can be an electric communication sent and received by the mobile device of the courier.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known technique of the communication by the virtual assistant device can be an electric communication sent and received by the mobile device of the courier (Swift, see at least: “By way of the above example, the list of offers, services, and/or other information (e.g., sales information for the customer or competitors of the customer) may be presented audibly to the delivery driver through a speaker of the mobile device and/or the vehicle communication device [i.e. wherein the communication by the virtual assistant device can be an electric communication sent and received by the mobile device of the courier]. In response, the mobile device and/or the vehicle communication device may receive a second voice command from the delivery driver” [0052]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi with Swift for the reasons identified above with respect to claim 1.
Regarding claim 14, Dhesi in view of Swift teaches the system of claim 1. Dhesi further discloses:
-wherein the courier device is configured to receive, process, and produce data during a food delivery pickup, delivery, and fulfilment stages of a food delivery process (Dhesi, see at least: “Courier devices 40 in some embodiments have a user interface for accepting incoming courier requests 900 as shown in FIG. 9A. The incoming courier request interface 900 may provide a lot of useful information to help couriers determine whether the courier is willing and able to provide pickup and deliver the order. Such information may include the time and date of the pickup 910, the time and location of the pickup 920, the time and location of the delivery 930, the order detail 940, and/or a map from the pickup location to the delivery location including an estimated travel time 950. The order details 940 on the courier display 900 may include details to help the courier better understand the size requirements of the courier job (e.g. that there is 100 meals in 8 chaffing dishes and 3 medium sized boxes) [i.e. wherein the courier device is configured to receive, process, and produce data during a food delivery pickup, delivery, and fulfilment stages of a food delivery]. In other embodiments, the order information 940 may include dimensions, weight, number of parcels, and so forth” [0101]).
Dhesi does not explicitly disclose courier device being a virtual assistant device.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known technique of the virtual assistant device being configured to receive, process, and produce data during a delivery pickup, delivery, and fulfilment stages of a delivery process (Swift, see at least: “the method may further include transmitting the first set of information based on the first voice command through speech and in response to receiving a second voice command from the user, such that the second voice command interacts with the first set of information, processing the second voice command to determine a final set of information to transmit to the user [i.e. wherein the virtual assistant device is configured to receive, process, and produce data] … the list of offers, services, and/or other information (e.g., sales information for the customer or competitors of the customer) may be presented audibly to the delivery driver through a speaker of the mobile device and/or the vehicle communication device … In response, the mobile device, the vehicle communication device, and/or server may modify the presented list and curate a final set of information to be presented to the delivery driver. For instance, the apparatus and/or back-end system may contain sales history, sales in the region (what is selling in nearby locations with similar demographics, and using algorithms make suggestions. For example, the final set of information may include one or more offers, services, and/or other information accepted by the delivery driver as being relevant to the customer at the next delivery location [i.e. during a delivery pickup, delivery, and fulfilment stages of a delivery process]” [0052]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi with Swift for the reasons identified above with respect to claim 1.
Regarding claim 15, Dhesi in view of Swift teaches the system of claim 1.
Dhesi does not explicitly disclose the virtual assistant device being configured to audibly broadcast recommendations and information to the courier in order to prevent the courier from engaging with the mobile device of the courier.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known technique of the virtual assistant device being configured to audibly broadcast recommendations and information to the courier in order to prevent the courier from engaging with the mobile device of the courier (Swift, see at least: “While driving, the user or delivery driver may be prevented from accessing and using the interface or screen. The device may impose a “screen lock condition” on the device such that the driver is prevented from accessing and interacting with the visual display. Thus, instead of visually displaying sets of information to the driver, while driving, the device interacts with the driver solely by voice [i.e. wherein the virtual assistant device is configured to audibly broadcast recommendations and information to the courier]. A screen lock condition locks the interface to avoid visual display of a set of information. Such condition may be in response to the processor determining that the apparatus is in transit to a desired location” [0050] and “the screen lock condition may be activated by locking an interface available to the user to avoid visual display [i.e. in order to prevent the courier from engaging with the mobile device of the courier] of a set of information in response to determining that the user is in transit to the desired location” [0015]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi with Swift for the reasons identified above with respect to claim 1.
Regarding claim 19, Dhesi discloses a method for processing orders for food through a network processor and transmitting the orders for food to a courier, the method comprising:
-transmitting, by a customer processor at a customer location, a food order through the network processor (Dhesi, see at least: “The client device 10 may transmit this order [i.e. transmitting, by a customer processor at a customer location, a food order] to a fulfillment engine 20. In an exemplary embodiment, fulfillment engine 20 is managed, operated, or facilitated (and/or in some embodiments, owned) by a service provider” [0042] and “Client device 10 may be, for instance, a mobile device such as smart phone, tablet, computer, laptop, or other electronic device that can communicate via a network (not specifically shown) [i.e. through the network processor]” [0040] and “Client 12, via device 10, may send one or more orders 201-1 to a fulfillment engine 20. An order may include information such as the number of meals to deliver [i.e. a food order]” [0052]);
-receiving, by a delivery service processor at a delivery service location, the food order through the network processor (Dhesi, see at least: “The client device 10 may transmit this order to a fulfillment engine 20. In an exemplary embodiment, fulfillment engine 20 is managed, operated, or facilitated (and/or in some embodiments, owned) by a service provider [i.e. receiving, by a delivery service processor at a delivery service location, the food order]” [0042] and “Client device 10 may be, for instance, a mobile device such as smart phone, tablet, computer, laptop, or other electronic device that can communicate via a network (not specifically shown) [i.e. through the network processor]” [0040]);
-transmitting, by the delivery service processor, through the network processor the food order to a merchant processor at a merchant location (Dhesi, see at least: “Fulfillment engine 20 transmits [i.e. transmitting, by the delivery service processor] and/or receives order data [i.e. the food order], profile/preference data, fulfillment data, and/or feedback data, etc. to/from one or more of merchant devices 30 [i.e. to a merchant processor at a merchant location] and customer devices 10 (such transmissions shown in FIG. 1A with solid lines). These types of data transmission are performed over a communication network (not specifically shown) [i.e. through the network processor]” [0047]);
-receiving and processing, by the merchant processor, the food order from the delivery service processor through the network processor (Dhesi, see at least: “The fulfillment engine 20 sends order information 202-2 to the merchant device 30 [i.e. receiving, by the merchant processor, the food order from the delivery service processor] corresponding to the merchant 32 that the fulfillment engine 20 deems optimal for fulfilling the client's order. This determination is done by way of an optimizer algorithm 212, which will be discussed later in greater detail. In an embodiment where the service provider is a catering service provider and the client has requested the delivery of one or more meals, the fulfillment server 20 may focus solely on merchants proximate to the client to ensure that the meal is prepared and delivered in a relatively quick timeframe required by the meal, filtering out, discarding, and/or otherwise disfavoring merchants from fulfillment of an order where they are at a location deemed to be too far from or non-proximate to the client” [0056] and “At step 325 the order (or information about the order, such as the order items, destination, and/or delivery date/time) is sent to the merchant 32. At step 330, the most optimal merchant 30 receives the order. Step 332 involves a decision by the merchant as to whether it accepts the order [i.e. receiving and processing, by the merchant processor, the food order]. In some embodiments, the merchant 32 is under contract to be able to produce a certain number of items for the fulfillment engine 20. In this case, the merchant 32 would only reply to the fulfillment engine 20 with a confirmation message (Yes, in response to step 332)” [0078] and “Merchant device 30 may be, for instance, a mobile device such as a smart phone, tablet, computer, laptop, or other electronic device that can communicate with the fulfillment engine via a network (not specifically shown) [i.e. through the network processor]” [0044]);
-transmitting, by the merchant processor, through the network processor a signal to the delivery service processor accepting the food order (Dhesi, see at least: “At step 325 the order (or information about the order, such as the order items, destination, and/or delivery date/time) is sent to the merchant 32. At step 330, the most optimal merchant 30 receives the order. Step 332 involves a decision by the merchant as to whether it accepts the order. In some embodiments, the merchant 32 is under contract to be able to produce a certain number of items for the fulfillment engine 20. In this case, the merchant 32 would only reply to the fulfillment engine 20 with a confirmation message (Yes, in response to step 332) [i.e. transmitting, by the merchant processor, through the network processor a signal to the delivery service processor accepting the food order]” [0078] and “Merchant device 30 may be, for instance, a mobile device such as a smart phone, tablet, computer, laptop, or other electronic device that can communicate with the fulfillment engine via a network (not specifically shown) [i.e. through the network processor]” [0044]); and
-transmitting, by the delivery service processor, through the network processor the food order to a courier device at a courier location (Dhesi, see at least: “a merchant has confirmed acceptance of the order but does not provide its own delivery, therefore, control passes to Step 335 to send an order to an optimal courier (step 340) for delivery of the order [i.e. transmitting, by the delivery service processor, through the network processor the food order to a courier device at a courier location]. Other configurations may be possible in other embodiments, for example, where the merchant provides delivery fulfillment and no third party courier is needed. The courier may also determine its availability to fulfill the order at step 342, and if not available (No in step 342), the process cycles back to step 320 and the order is transmitted to the next most optimal courier (or in some cases, the next most optimal merchant if no courier is available). If the courier confirms available (Yes in step 342), the process continues to step 345” [0080] and “FIG. 1A further illustrates one or more courier systems 42, each using at least one courier device 40, which may be, for instance, a smart phone, tablet, computer, laptop, or other electronic device that can communicate with the fulfillment engine via a network (not specifically shown) [i.e. through the network processor]” [0045] and Fig. 3);
-receiving and processing, by the courier device, the food order from the delivery service processor (Dhesi, see at least: “a merchant has confirmed acceptance of the order but does not provide its own delivery, therefore, control passes to Step 335 to send an order to an optimal courier (step 340) for delivery of the order. Other configurations may be possible in other embodiments, for example, where the merchant provides delivery fulfillment and no third party courier is needed. The courier may also determine its availability to fulfill the order at step 342 [i.e. receiving and processing, by the courier device, the food order from the delivery service processor], and if not available (No in step 342), the process cycles back to step 320 and the order is transmitted to the next most optimal courier (or in some cases, the next most optimal merchant if no courier is available). If the courier confirms available (Yes in step 342), the process continues to step 345” [0080] and Fig. 3); and
-displaying, by the courier device, the data associated with the food order to the courier (Dhesi, see at least: “Courier devices 40 in some embodiments have a user interface for accepting incoming courier requests 900 as shown in FIG. 9A. The incoming courier request interface 900 may provide a lot of useful information to help couriers determine whether the courier is willing and able to provide pickup and deliver the order. Such information may include the time and date of the pickup 910, the time and location of the pickup 920, the time and location of the delivery 930, the order detail 940, and/or a map from the pickup location to the delivery location including an estimated travel time 950. The order details 940 on the courier display 900 [i.e. displaying, by the courier device, the data associated with the food order to the courier] may include details to help the courier better understand the size requirements of the courier job (e.g. that there is 100 meals in 8 chaffing dishes and 3 medium sized boxes” [0101]).
Dhesi does not explicitly disclose the courier device being a virtual assistant device; and audibly broadcasting, by the virtual assistant device, the data associated with the food order and recommendations based on the data associated with the food order to the courier.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known technique of the courier device being a virtual assistant device (Swift, see at least: “the list of offers, services, and/or other information (e.g., sales information for the customer or competitors of the customer) may be presented audibly to the delivery driver through a speaker of the mobile device and/or the vehicle communication device [i.e. the courier device being a virtual assistant device]. In response, the mobile device and/or the vehicle communication device may receive a second voice command from the delivery driver” [0052]); and
the known technique of audibly broadcasting, by the virtual assistant device, the data associated with the order and recommendations based on the data associated with the order to the courier (Swift, see at least: “an apparatus, such as a mobile device carried by a delivery driver and/or a vehicle communication device, may receive a first voice command from the delivery driver requesting information from the apparatus. The apparatus may process the first voice command and determine a first set of information to present to the delivery driver [i.e. audibly broadcasting, by the virtual assistant device, the data] … The set of information may then be more specific information (“items of information”) such as certain training modules, tips, sales performance, next stop information (e.g., products to be delivered and how many, special requirements/procedures/interests of the next stop) [i.e. the data associated with the order]” [0049] and “the list of offers, services, and/or other information (e.g., sales information for the customer or competitors of the customer) may be presented audibly to the delivery driver through a speaker of the mobile device and/or the vehicle communication device [i.e. audibly broadcasting, by the virtual assistant device]. In response, the mobile device and/or the vehicle communication device may receive a second voice command from the delivery driver. By way of an example, the second voice command may include a response, such as “Accept,” “Reject,” “Next”, to accept or reject one or more offers, services, and/or information from the presented list. The response may be received via a microphone of the mobile device and/or the vehicle communication device. In response, the mobile device, the vehicle communication device, and/or server may modify the presented list and curate a final set of information to be presented to the delivery driver. For instance, the apparatus and/or back-end system may contain sales history, sales in the region (what is selling in nearby locations with similar demographics, and using algorithms make suggestions. For example, the final set of information may include one or more offers, services, and/or other information accepted by the delivery driver as being relevant to the customer at the next delivery location [i.e. recommendations based on the data associated with the order to the courier]” [0052]). These known techniques are applicable to the method of Dhesi as they both share characteristics and capabilities, namely, they are directed to delivering items from a store.
It would have been recognized that applying the known techniques of the courier device being a virtual assistant device; and audibly broadcasting, by the virtual assistant device, the data associated with the order and recommendations based on the data associated with the order to the courier, as taught by Swift, to the teachings of Dhesi would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such references into similar methods. Further, adding the modifications of the courier device being a virtual assistant device; and audibly broadcasting, by the virtual assistant device, the data associated with the order and recommendations based on the data associated with the order to the courier, as taught by Swift, into the method of Dhesi would have been recognized by those of ordinary skill in the art as resulting in an improved method that would utilize dead-time between stops effectively and adhering to safety requirements (Swift, [0049]).
Claims 16-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Dhesi, in view of Swift, in further view of Crow et al. (US 2016/0162865 A1) hereinafter Crow.
Regarding claim 16, Dhesi in view of Swift teaches the system of claim 1.
Dhesi does not explicitly disclose the recommendations being audibly broadcast by the virtual assistant device to the courier including recommendations regarding accepting or declining the food order.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known technique of the recommendations being audibly broadcast by the virtual assistant device to the courier (Swift, see at least: “the method may further include transmitting the first set of information based on the first voice command through speech and in response to receiving a second voice command from the user, such that the second voice command interacts with the first set of information, processing the second voice command to determine a final set of information to transmit to the user … the list of offers, services, and/or other information (e.g., sales information for the customer or competitors of the customer) may be presented audibly to the delivery driver through a speaker of the mobile device and/or the vehicle communication device [i.e. wherein the recommendations being audibly broadcast by the virtual assistant device to the courier] … For example, the final set of information may include one or more offers, services, and/or other information accepted by the delivery driver as being relevant to the customer at the next delivery location” [0052] and “For example, an apparatus, such as a mobile device carried by a delivery driver and/or a vehicle communication device, may receive a first voice command from the delivery driver requesting information from the apparatus. The apparatus may process the first voice command and determine a first set of information to present to the delivery driver … The points of interest may include various topics such as training, sales, routing information, next stop information, remaining stops information, surveys, suggestions for sales/products [i.e. the recommendations], new product information, pricing information, and messages for the delivery driver” [0049]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi with Swift for the reasons identified above with respect to claim 1.
Dhesi in view of Swift does not explicitly teach recommendations regarding accepting or declining the food order.
Crow, however, teaches assigning tasks to drivers (i.e. [0003]), including the known technique of the recommendations being regarding accepting or declining the food order (Crow, see at least: “Before accepting the route, the on-line system 100 may propose a StS based change. For example, in FIG. 2 a product change is suggested to increase the inventory of one project and decrease the inventory of another product. The suggestion is either accepted or rejected [i.e. recommendations regarding accepting or declining the food order], as shown in FIG. 2” [0038]). This known technique is applicable to the system of Dhesi in view of Swift as they both share characteristics and capabilities, namely, they are directed to assigning tasks to drivers.
It would have been recognized that applying the known technique of the recommendations being regarding accepting or declining the food order, as taught by Crow, to the teachings of Dhesi in view of Swift would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such references into similar systems. Further, adding the modification of the recommendations being regarding accepting or declining the food order, as taught by Crow, into the system of Dhesi in view of Swift would have been recognized by those of ordinary skill in the art as resulting in an improved system that would maximize profits (Crow, [0036]).
Regarding claim 17, the combination of Dhesi/Swift/Crow teaches the system of claim 16.
Dhesi in view of Swift does not explicitly teach the recommendations regarding accepting or declining the food order being based on a profitability of delivery of the food order.
Crow, however, teaches assigning tasks to drivers (i.e. [0003]), including the known technique of the recommendations regarding accepting or declining the food order being based on a profitability of delivery of the food order (Crow, see at least: “The prediction logic of the central application lists only the machines at such a location that are profitable to visit that day” [0050] and “Applicant determined profitable vending operations must balance these three parameters such that the route manager visits only the maximally profitable machines so the sales receipts collected are maximized vs. the fixed expense of the visits” [0016] and “through the use of real-time validation and verification, a variable compensation plan is enabled where accuracy and adherence to policy is deterministically rewarded. For example, a driver properly employing the protocols of FIGS. 27, 28 may increase profits and his or her compensation” [0059]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi in view of Swift with Crow for the reasons identified above with respect to claim 16.
Regarding claim 18, the combination of Dhesi/Swift/Crow teaches the system of claim 17.
Dhesi in view of Swift does not explicitly teach the profitability of delivery of the food order being based on at least one of fuel efficiency of a delivery vehicle, total drive distance to complete the food order, traffic conditions, and total food order price.
Crow, however, teaches assigning tasks to drivers (i.e. [0003]), including the known technique of the profitability of delivery of the food order being based on at least one of fuel efficiency of a delivery vehicle, total drive distance to complete the food order, traffic conditions, and total food order price (Crow, see at least: “Applicant determined profitable vending operations must balance these three parameters such that the route manager visits only the maximally profitable machines so the sales receipts collected are maximized vs. the fixed expense of the visits [i.e. wherein the profitability of delivery of the food order is based on at least one of fuel efficiency of a delivery vehicle, total drive distance to complete the food order, traffic conditions, and total food order price]. This system must be maintained by precisely accurate stocking of the truck at the start of the day and along the route such that each visited machine is stocked to its maximum production capacity” [0016] and “This criticality is based on at least the following three issues. First, each visit to a machine has a relatively fixed cost which includes wages for the driver, transportation expenses [i.e. based on fuel efficiency of a delivery vehicle], depreciation of corporate assets, and others” [0015]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Dhesi in view of Swift with Crow for the reasons identified above with respect to claim 16.
Regarding claim 20, Dhesi in view of Swift teaches the method of claim 19.
Dhesi does not explicitly disclose the recommendations being audibly broadcast by the virtual assistant device to the courier include recommendations regarding accepting or declining the food order.
Swift, however, teaches delivering items from a store (i.e. abstract), including the known technique of the recommendations being audibly broadcast by the virtual assistant device to the courier (Swift, see at least: “the method may further include transmitting the first set of information based on the first voice command through speech and in response to receiving a second voice command from the user, such that the second voice command interacts with the first set of information, processing the second voice command to determine a final set of information to transmit to the user … the list of offers, services, and/or other information (e.g., sales information for the customer or competitors of the customer) may be presented audibly to the delivery driver through a speaker of the mobile device and/or the vehicle communication device [i.e. wherein the recommendations being audibly broadcast by the virtual assistant device to the courier] … For example, the final set of information may include one or more offers, services, and/or other information accepted by the delivery driver as being relevant to the customer at the next delivery location” [0052] and “For example, an apparatus, such as a mobile device carried by a delivery driver and/or a vehicle communication device, may receive a first voice command from the delivery driver requesting information from the apparatus. The apparatus may process the first voice command and determine a first set of information to present to the delivery driver … The points of interest may include various topics such as training, sales, routing information, next stop information, remaining stops information, surveys, suggestions for sales/products [i.e. the recommendations], new product information, pricing information, and messages for the delivery driver” [0049]).
Dhesi in view of Swift does not explicitly teach the recommendations being regarding accepting or declining the food order.
Crow, however, teaches assigning tasks to drivers (i.e. [0003]), including the known technique of the recommendations being regarding accepting or declining the food order (Crow, see at least: “Before accepting the route, the on-line system 100 may propose a StS based change. For example, in FIG. 2 a product change is suggested to increase the inventory of one project and decrease the inventory of another product. The suggestion is either accepted or rejected [i.e. recommendations regarding accepting or declining the food order], as shown in FIG. 2” [0038]). This known technique is applicable to the method of Dhesi in view of Swift as they both share characteristics and capabilities, namely, they are directed to assigning tasks to drivers.
It would have been recognized that applying the known technique of the recommendations being regarding accepting or declining the food order, as taught by Crow, to the teachings of Dhesi in view of Swift would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such references into similar methods. Further, adding the modification of the recommendations being regarding accepting or declining the food order, as taught by Crow, into the method of Dhesi in view of Swift would have been recognized by those of ordinary skill in the art as resulting in an improved method that would maximize profits (Crow, [0036]).
Response to Arguments
Rejections under 35 U.S.C. §101
Applicant argues that the recited limitations reflect a hands-free, safety- and efficiency-oriented integrated into a multi-actor delivery network and are not merely "doing business on a computer" as the Office Action's characterization is overbroad and fails to recognize key limitations of the claims. Regarding Step 2A, Prong 1: the claims are not properly characterized as merely a commercial interaction. The claims require, among other things: 1. a virtual assistant device at the courier location that is communicatively coupled to the courier's mobile device; 2. the virtual assistant receives food order data, processes that food order data, and produces recommendations based on that food order data; and 3. the recommendations are at least audibly broadcast to the courier. The dependent claims further specify the presence and use of speech 1/0 components (speaker/microphone), and in certain claims, an in-motion interface constraint (touchscreen partially disabled while in motion) and/or audible output configured to prevent courier engagement with the mobile device while the courier is driving. These limitations are not captured by the Office Action's abstraction (Remarks, pages 9-11).
Examiner respectfully disagrees. Initially, Examiner points out that under Prong 1 of Step 2A it is determined whether the claims are directed to a judicially recognized exception, it is not until Prong 2 of Step 2A that it is determined whether the claim recites additional elements that integrate the exception into a practical application of the exception. Examiner analyzed all of the recited limitations of the submitted claims and, as indicated by the bolded portions of the recited claims, the limitations recite the concept of processing food orders and providing recommendations to couriers regarding the food orders. This falls within “Certain Methods of Organizing Human Activity” groupings of abstract ideas, enumerated in MPEP 2106.04(a), as it encompasses advertising, and marketing or sales activities. Additionally, even when the additional elements are considered under Prong 2, the additional elements are recited at a high level of generality (i.e. as generic computing hardware) such that they amount to nothing more than mere instructions to implement or apply the abstract idea on a generic computing hardware (or, merely use a computer as a tool to perform an abstract idea). Merely reciting speech 1/0 components (speaker/microphone), an in-motion interface constraint (touchscreen partially disabled while in motion) and/or audible output fails to i) reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, ii) apply the judicial exception with, or use the judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim, iii) effect a transformation or reduction of a particular article to a different state or thing, or iv) apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. Furthermore, improving safety and efficiency for a driver by merely providing audible outputs is not a technical solution as the generic computing components themselves, even when looked at in combination, are not improved. Accordingly, the claims are ineligible.
Applicant further argues that, under Prong 2 of Step 2A, the claims provide a practical application. Even assuming arguendo that an abstract idea can be identified even at a high level, the claims integrate any such idea into a practical application by reciting a particular arrangement of devices and operations that improves how the courier receives and acts on delivery information, including when the courier is driving. Specifically, the claims require a courier-location virtual assistant architecture that generates recommendations from food order data and broadcasts those recommendations audibly, enabling hands-free operation. In dependent claims, the system is further constrained by in-motion disablement and/or anti-engagement features for safe operation while in transit. These limitations provide a particular technical implementation tied to physical-world constraints (use while mobile and driver distraction), and thus amount to a practical application rather than a mere instruction to "apply it on a computer" (Remarks, page 11).
Examiner respectfully disagrees. Improvement of the actions of the courier is not a technological improvement, it’s a business improvement. Improving safety and efficiency for a driver by merely providing audible outputs is not a technical solution as the generic computing components themselves, even when looked at in combination, are not improved. Additionally, regarding in-motion disablement and/or anti-engagement features, MPEP 2106.05(a) states that “the claim must be evaluated to ensure the claim itself reflects the disclosed improvement in technology,” however, the current claims do not recite how the display is partially disabled (i.e. the specific technical elements that implement this feature). Accordingly, the claims are ineligible.
Applicant further argues that, under step 2B, the claims recite an inventive concept in the ordered combination. The Office Action further concludes there is no "significantly more," asserting the elements are conventional and generic. Applicant respectfully disagrees. The ordered combination is not simply taking orders sharing information with a courier. The claims recite: (i) a multi-processor network and accept/decline signaling, plus (ii) a distinct virtual assistant device at the courier location coupled to the courier mobile device that processes food order data to generate recommendations and audibly broadcasts those recommendations, and, in dependent claims, further constrained by movement and safety features. It is submitted that this is "significantly more" (Remarks, page 12).
Examiner respectfully disagrees. Merely reciting the use of processors, a network, and a virtual assistant device coupled to the courier mobile device to implement the recited abstract idea, even when taken individually or as a whole, do not add anything significantly more than when considered individually. For instance, each of the recited additional elements are merely utilized in a generic manner. Accordingly, the claims are ineligible.
Rejections under 35 U.S.C. §103
Applicant argues that the Office Action acknowledges Dhesi does not disclose claimed features: "Dhesi does not explicitly disclose a virtual assistant device at a courier location, the virtual assistant device being communicatively coupled to a mobile device of the courier, wherein the virtual assistant device is configured to receive food order data, process the food order data, and produce recommendations based on the food order data, with the recommendations being at least audibly broadcast to the courier." For those features, the Office Action relies on Swift. Applicant submits the proposed combination is flawed for at least the following reasons. Swift is cited for vehicle/mobile device audible presentation and voice commands. However, the independent claims require more than just audible presentation. They require a virtual assistant device at the courier location that is communicatively coupled to the courier mobile device and that produces recommendations based on food order data and broadcasts those recommendations audibly. The relied-upon teachings of Swift do not disclose or suggest integrating Swift's audio/voice interface into Dhesi in a manner that results in the claimed courier-side virtual assistant device that processes food order data to generate food-order-specific recommendations as claimed (Remarks, pages 12-13).
Examiner respectfully disagrees. Swift teaches that the server, which is coupled with the mobile device and/or the vehicle communication device [i.e. a virtual assistant device at the courier location] via a network [i.e. that is communicatively coupled to the courier mobile device], receives a voice command, determines product information such as products to be delivered, offers, and how many [i.e. receive order data], and audibly presents one or more offers, services, and/or other information accepted by the delivery driver as being relevant to the customer at the next delivery location [i.e. process the order data, and produce recommendations based on the order data] (see Swift, [0052], [0058], [0059], [0049], [0052], and Fig. 1). Additionally, the server is run on the mobile device and/or the vehicle communication device as an application [i.e. a virtual assistant device at the courier location] (see Swift, [0047]) and paragraph [0019] of Applicant’s specification indicates that the virtual assistant device at a courier location is a software component deployed on or within the mobile device of the courier. Accordingly, the cited references teach the recited claims.
Applicant further argues that the Office Action asserts it would have been obvious to apply Swift's techniques to Dhesi for predictable results and to utilize "dead-time" and adhere to safety requirements. This does not explain why a person of ordinary skill in the art (POSITA) would modify Dhesi to add (i) a separate virtual assistant device coupled to the courier mobile device and (ii) recommendation generation based on food order data with audible broadcast, instead of simply providing generic audible notifications on the courier mobile device already disclosed by Dhesi. Thus, the rationale provided for combining the references is conclusory, and no motivation or suggestion is provided by either reference for making such meaningful changes to Dhesi to arrive at the subject claims. "[A] conclusory assertion with no explanation is inadequate to support a finding that there would have been a motivation to combine. This type of finding, without more, tracks the ex post reasoning KSR warned of and fails to identify any actual reason why a skilled artisan would have combined the elements in the manner claimed." In re Van Os, 844 F.3d 1359, 1361 (Fed. Cir. 2017).
Examiner respectfully disagrees. As indicated in paragraph [0019] Applicant’s spec, the virtual assistant device includes a software component deployed on or within the mobile device of the courier. Accordingly, the addition of this software (i.e. the virtual assistant device) to the courier mobile device of Dhesi would have been recognized by those of ordinary skill in the art as resulting in an improved system that would utilize dead-time between stops effectively and adhere to safety requirements (Swift, [0049]) as it would allow for the recommendations to be audibly broadcast while the screen is locked in between stops. Thus, Dhesi and Swift are obvious to combine.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
-Gjertson et al. (US 11,741,528 B1) teaches providing an option to accept or reject recommendations.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARIELLE E WEINER whose telephone number is (571)272-9007. The examiner can normally be reached M-F 8:30-5:00.
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, Maria-Teresa (Marissa) Thein can be reached at 571-272-6764. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ARIELLE E WEINER/ Primary Examiner, Art Unit 3689
Prosecution Insights