DETAILED ACTION
This Office Action is in response to Applicants Request for Continued Examination received on January 21, 2026. Claim(s) 1-5, 7-15, and 17-20 is/are currently pending in the instant application.
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 .
Response to Amendment
The Examiner acknowledges the Applicants amendments to claims 1 and 11 in the response on January 21, 2026. Claims 6 and 16 were previously canceled.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 3, 7-11, 13, and 17-20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hitachi, LTD WO 2022/035370 A1 (hereafter Hitachi)
Regarding claim 1, receiving a task batch from an online system, wherein the task batch comprises an ordered sequence of task units for tasks to be performed by a user corresponding to the client device (see at least Fig. 6, [0079] a schematic illustration of a task map user interface 601 (e.g., corresponding to the task map user interface as described hereinbefore according to various embodiments) provided or displayed on a display screen of an example portable computing device (e.g., a smartphone), according to various example embodiments of the present invention. As shown, in the example, the assigned tasks “Al” 602a, “A2” 602b and “A3” 602c (e.g., corresponding to the plurality of task elements at a plurality of positions as described hereinbefore according to various embodiments) are displayed on a map portion of the task map user interface 601.);
displaying a first task UI through a client application operating on the client device, wherein the first task UI corresponds to a task unit of the ordered sequence of task units (see at least Fig. 7, task A2 [0080] schematic illustration of an example task detail user interface 701 (e.g., corresponding to the task detail user interface as described hereinbefore according to various embodiments) provided or displayed on a display screen of the example portable computing device, according to various example embodiments of the present invention. As shown, the task detail user interface 701 comprises a task detail portion 702 and a sub-task portion including a plurality of sub-task elements 703a, 703b, and 703c (corresponding to a plurality sub-tasks of the task). In various example embodiments, when one of tasks on the task map user interface 601 is tapped, the task map user interface 601 is switch or transitioned to the task detail user interface 701 to provide or display the task information corresponding to the selected task (i.e., which was tapped).);
receiving an interaction with the first task UI indicating completion of the task unit associated with the first task UI (see at least [0079] when one of tasks on the task map user interface 601 is tapped, the task map user interface 601 is switch or transitioned to the task detail user interface 701 to provide or display the task information corresponding to the selected task (i.e., which was tapped).);
responsive to receiving the interaction, identifying a next task unit of the ordered sequence of task units (see at least Fig. 9, subsequent tasks [0084] , other sub-tasks such as 902b and 902c may be switched to be displayed in turn on the display screen based on a predetermined user input, such as a predetermined touch, gesture and/or motion input (e.g., a flick motion). For example, based on another user input (e.g., a single tap), the current sub-task may be treated as completed and the next sub-task may be displayed on the display screen.);
accessing template user interfaces from the online system, wherein each template user interface includes information describing instructions for completion of a task unit type and one or more populatable fields for populating with information for a specific task unit of the task unit type (see at least Fig. 7 [0080] when one of tasks on the task map user interface 601 is tapped, the task map user interface 601 is switch or transitioned to the task detail user interface 701 to provide or display the task information corresponding to the selected task (i.e., which was tapped). For example, the task detail portion 702 may provide or display detailed information relating to the selected task. Similarly, each sub-task element 703a, 703b, and 703c may provide or display detailed information relating to the corresponding sub-task element. [0081] the task detail user interface 701 may include a first interactive update element (e.g., a first interactive update button) 704, such as in the form of a “Mark Start” button, configured to trigger an update of the status information, such as recording or reporting the start of the task. In various example embodiments, the plurality of sub-task elements 703a, 703b, and 703c may include a plurality of second update elements 705a, 705b, and 705c, respectively, such as in the form of checkboxes, configured to trigger an update of the corresponding subtask status information, such as recording or reporting the completion time of the corresponding sub-task. For example, when the check box of a subtask is tapped, the completion time 706 may be recorded and/or displayed. If there are multiple sub-tasks which cannot all be displayed in the display screen at once due to the limited display area, the user may scroll the task detail user interface 701 to view the remaining subtasks. When a first interactive switch element (e.g., a first interactive switch button 707, such as a back button,) (e.g., corresponding to the first interactive switch element as described hereinbefore according to various embodiments) is tapped, task map user interface 601 may be displayed again. In various example embodiments, the status information of the task information may be updated by each status update triggered by the user, and the status information as updated (e.g., each update) may be transmitted to the task control system at the command center so that the command center is aware of the status of the tasks assigned.);
generating a user interface (UI) state machine comprising a set of UI states and a set of state transitions for transitioning between UI states, wherein each UI state of the set of UI states corresponds to a task UI for displaying a task for the user to perform and is generated by populating information from one task unit in the ordered sequence of task units into populatable fields of a corresponding template user interface, and wherein each state transition comprises a start state, an end state, and a transitioning task unit (see at least Fig. 14, [0089] FIG. 14 depicts a schematic state transition diagram of an example state machine 1400 according to the method of task management as described hereinbefore with reference to FIGs 12 and 13, configured to change (or transition) from one state to another in response to certain input(s). In particular, FIG. 14 illustrates the state transition associated with the example state machine 1400 based on various inputs shown. The example state machine 1400 may include three states, namely, a first state 1401 (e.g., corresponding to the first state 801) corresponding to the state in which the task map user interface 1301 is provided, a second state 1402 (e.g., corresponding to the second state 802) corresponding to the state in which the task detail user interface 701 is provided, and a third state 1403 corresponding to the state in which the task list user interface 1201 is provided.);
identifying a first current state of the UI state machine, wherein the first current state is a state of the set of UI states and corresponds to the first task UI that is displayed by the client device (see at least Fig. 14, task map 1401);
identifying a task unit type of the next task unit (see at least Fig. 14, transition from 1401 to 1402 or 1403 based on list of task “taps”);
generating a second task UI by populating the one or more populatable fields with information from the task batch and associated with the next task unit (see at least Fig. 11 [0086], ask map user interface 1101 may be the same as the example task map user interface 601 as described hereinbefore or the example task map user interface 1301 as will be described later below according to various example embodiments, except that the task detail user interface 1101 further includes a route indication from one task to the immediate nest task amongst the tasks. In particular, by connecting immediate adjacent tasks on the map portion with a route indication, such as in the form of an arrow 1101a or 1101b, the user is able to better understand the sequence of the tasks.);
identifying a state transition of the set of state transitions that corresponds to the first current state of the UI state machine and the task unit type of the next task unit (see at least Fig. 13, map interface, Fig. 12, list interface, Fig. 10, detail interface, Fig. 14, transition path between states);
identifying an end state associated with the identified state transition (see at least Fig. 13, A1-A3 complete, Fig. 17, report detail and submission);
transitioning the UI state machine to a second current state corresponding to the end state (see at least Fig. 17); and
causing a display transition from the first task UI displayed by the client device to the second task UI corresponding to the second current state (see at least Figs. 10, 12, 13, and 14).
Regarding claim 3, wherein identifying the next task unit of the ordered sequence of task units comprises: identifying a first task unit of the ordered sequence of task units (see at least Fig. 6, tasks A1-3).
Regarding claim 7, wherein the first current state and the second current state correspond to different UI states in the set of UI states (see at least Fig. 14).
Regarding claim 8, wherein the first current state and the second current state correspond to the same UI state of the set of UI states (see at least Fig. 12, [0038] each of the plurality of task items further includes status information relating to the task item. In various embodiments, the status information relating to the task item may indicate a status of the corresponding task, such as but not limited to, not yet started, in progress, completed, problem encountered, and so on, along corresponding time information where appropriate (e.g., start time and completed time). In various embodiments, the method 100 further comprises updating, in response to a seventh user input selecting a first status update option with respect to the task detail user interface, the status information relating to the task item corresponding to the task detail user interface. In various embodiments, similarly, the seventh user input selecting the first status update option with respect to the task detail user interface may be any form of user input for triggering (or causing) the update of the status information relating to the task item, such as but not limited to, a predetermined touch, gesture and/or motion input made by the user (e.g., a single tap or a short press) on or with respect to an interactive first update element (e.g., a first interactive update button) in the task detail user interface displayed on the display screen or a predetermined voice input made by the user with respect to the task detail user interface, such as corresponding to the first status update option. Same UI state where the status indicator is updated/ toggled).
Regarding claim 9, wherein updating the first task UI to the second task UI comprises: updating information displayed in the first task UI based on information associated with the next task unit (see at least [0041] the eighth user input selecting the second status update option with respect to one of the plurality of sub-task elements in the task detail user interface may be any form of user input for selecting the one of the plurality of sub-task elements for triggering (e.g., causing) the switch with respect to the selected sub-task element based on the state machine, such as but not limited to, a predetermined touch, gesture and/or motion input made by the user (e.g., a single tap or a short press) on or with respect to a second interactive update element (e.g., a second interactive update button) in the desired sub-task element displayed on the display screen or a predetermined voice input made by the user with respect to the desired sub-task element, such as corresponding to the second status update option or a name or identity of the desired sub-task element.).
Regarding claim 10, further comprising: receiving additional task units from the online concierge system; and
updating the task batch by inserting the additional task units into the ordered sequence of task units of the task batch (see at least [0094] based on updated status information received (or the lack of an updated status information) from a user, if an assigned task has taken shorter or longer than expected to complete, the task control system 1501 and/or the management staff in the command center may change or modify the assignment of the task, such as to a different individual or to additional individual(s). In this regard, the task control system 1501 may update the task information or generate new task information and send it to the relevant individual(s) to carry out. By way of an example only and without limitation, this may apply to cases where the transit time changes due to unexpected events such as traffic congestions).
Claim 11 is substantially similar to claim 1 and therefore rejected under the same rationale.
Claim 13 is substantially similar to claim 3 and therefore rejected under the same rationale.
Claim 17 is substantially similar to claim 7 and therefore rejected under the same rationale.
Claim 18 is substantially similar to claim 8 and therefore rejected under the same rationale.
Claim 19 is substantially similar to claim 9 and therefore rejected under the same rationale.
Claim 20 is substantially similar to claim 10 and therefore rejected under the same rationale.
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.
Claim(s) 2, 4, 5, 12, 14, and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hitachi, LTD WO 2022/035370 A1 (hereafter Hitachi) in view of Rademaker U.S. Publication 2014/0074743 A1 (hereafter Rademaker).
Regarding claim 2, Hitachi discloses that of claim 1 with task units and user interfaces but fails to detail where the task are performed at retail location.
Rademaker discloses, in the same field of invention, the retail sequence for curb-side delivery where an wherein the ordered sequence of task units comprises task units for tasks to be performed at a plurality of retailer locations (see at least Fig. 1 [0018] A customer uses a pickup management system to order a first product from a first retailer 92 and a second product from a second retailer 98. In some embodiments, the customer may communicate with the pickup management system using a mobile computing device, as will be discussed further below. The customer then uses a vehicle 90 to travel a path 91 to a first pickup location 96 near the first retailer 92. The pickup management system tracks the location of the customer and predicts a time at which the customer will arrive at the first pickup location 96. The pickup management system instructs the first retailer 92 to prepare the first product, such that the first product is ready at the predicted arrival time. The pickup management system may also guide the customer to the first pickup location 96 and may specify the first pickup location 96 with a high degree of precision, such as a particular parking spot, a particular side of the street, an approach path, and/or the like. An employee 94 of the first retailer 92 takes the first product to the first pickup location 96 at the predicted arrival time, and transfers it to the vehicle 90 of the customer. This includes the retail store receiving and order, picking the order, bagging or boxing the order, and transferring the order to the customer) therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use the task management method as disclosed in Hitachi with the retail order fulfillment process as taught by Rademaker for fulfilling orders at determined retailers as combining prior art elements is known to yield predictable results (KSR A)
Regarding claim 4, the combination discloses wherein each UI state of the set of UI states corresponds to a task unit type of a set of task unit types (Rademaker, receive order, pick/prepare order, complete order, deliver order to customer (vehicle or other).
Regarding claim 5, wherein the set of task unit types comprises at least one of a collection task unit type (Rademaker; picking or collecting order), a delivery task unit type (delivering order to vehicle or customer), a transport task unit type (Rademaker [00052] traditional method of fulfilling and shipping an order), or a bagging task unit type (boxing or bagging order to bring from store to customer/ vehicle).
Claim 12 is substantially similar to claim 2 and therefore rejected under the same rationale.
Claim 14 is substantially similar to claim 4 and therefore rejected under the same rationale.
Claim 15 is substantially similar to claim 5 and therefore rejected under the same rationale.
Response to Arguments
Applicant's arguments filed January 21 2026, have been fully considered. The argument begin with the rejection under 35 U.S.C § 101 where the Applicant goes over the analysis under each step and argues that under Step 2A, Prong 2 the additional elements integrate the exception into a practical application and under Step 2B, the additional elements are non-routing and unconventional activity (Remarks page 8-10).
The Applicant begins with Step 2A, Prong One and states that the amended limitations cannot be characterized as abstract ideas (remarks page 9). The arguments cite that the limitations are not mathematical concepts. That they are not certain methods of organizing human activity because data access and generation is rooted in computer technology and the limitations cannot be characterized as organizing human activity. Nor are they mental processes that can be performed using the human mind or pen and paper. The Applicants argue the human mind is incapable of data access, generating a UI state machine while leveraging interfaces, and therefore cannot be characterized as a mental process abstract idea.
The Examiner does not agree with the arguments. To start, the examiner never rejected the claims under the mathematical concepts grouping of abstract ideas. Regarding the grouping of certain methods of organizing human activity, the Examiner does not agree with the Applicants position. The idea that data access and generation is strictly limited to computer technology is not accurate or correct. Data can be stored in a paper file and interpreted and analyzed by a person. Further, the claims are directed to providing instructions to one or more persons through an interface. This is not more than applying the current technological field to the concept of providing instructions to workers. Additionally the concept of a state machine can be established in the mind with the transitions between the states. The application of a user interface and templates is merely application to the technical field.
The arguments move on to Step 2A, Prong Two where the Applicants position is that the additional elements are sufficient to integrate the judicial exception into a practical application (remarks page 10). The Applicants point to the alleged improvements to user interfaces in which the online system can batch tasks for each pickers sequence of task units. Further, leveraging template user interfaces to generate specific populatable fields with information form the task unit. Applicant states that this tailored flow guides the operative pickers through the sequence of task units.
The examiner agrees with the argument. The amendments to at least claims 1 and 11 include updating the UI interface and the Examiner concludes that the claims are integrated into a practical application.
Upon further search, the reference of Hitachi has been found and applied to the current claims.
In summary, the amendments and arguments have overcome the rejection under 35 U.S.C § 101. The claims are rejected under 35 U.S.C § 102 and 103. The claims are not in condition for allowance at the present time.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DYLAN C WHITE whose telephone number is (571)272-1406. The examiner can normally be reached M-F 7:30-4:00 EST.
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, Beth Boswell can be reached on (571)272-6737. 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.
/DYLAN C WHITE/Primary Examiner, Art Unit 3683 April 18, 2026
Prosecution Insights