CTNF 18/603,981 CTNF 101476 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 1. 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 § 103 07-20-aia AIA 2. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. 07-21-aia AIA 3. Claim s 1, 4-7, 10-14, and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over STURTIVANT Pub. No. US 2019/0286474 A1 in view of Krishnaraj et al. Pub. No. US 2010/0005472 A1 (hereafter Krishnaraj) . 4. Regarding claim 1, STURTIVANT teaches “… receiving a … request from a messaging application ([0004] & [0039] teaches an AP (automatic platform) issuing commands to the robotic process automation (RPA), the AP facilitating communication with respective RPA platforms) ; … generating a queue comprising one or more subtasks from the plurality of subtasks ([0046] teaches placing messages in respective processor queues based on data records of a certain type from a plurality of types) ; identifying an application programming interface associated with the one or more subtasks from the queue; routing the one or more subtasks to the application programming interface ([0005] teaches the AP transmitting the requests to a platform API of the platform-specific adapter, [0079] further teaches the routing of requests to a platform API for the RPA platform that is to execute the process ) ; receiving a response from the application programming interface associated with executing the one or more subtasks; and providing the response to the messaging application ([0079] teaches a response from the platform API that may provide an indication back to the controller, the controller part of the AP. [0052] also teaches further response conditions that may be transmitted back to a user) .” STURTIVANT does not explicitly teach receiving a multi-threaded request, and splitting the requests into subtasks. Krishnaraj teaches receiving a task and decomposing the task into subtasks such that it teaches the limitations “A method of asynchronous multi-threading comprising: receiving a multi-threaded task request from a messaging application ([0030-0036] teaches a message generator receiving a task request. The task may comprise of various tasks and may be decomposed into one or more discrete subtasks) ; … dividing the multi-threaded task request into a plurality of subtasks based on metadata associated with the multi-threaded task requests ([0046-0051] teaches task decomposition, decomposing a task into discrete subtasks associated with a type, the type being the metadata of the task) ”. It would have been obvious to a person of ordinary skill in the art before the effective filing date to combine the teachings of Krishnaraj to the invention of STURTIVANT for implementing task decomposition techniques to divide a multi-threaded request into subtasks. A person having ordinary skill in the art would have been motivated to make this combination in order to cut costs and achieve scalability, performance, and load balancing ([Krishnaraj [0196]. 5. Regarding claim 7, it is similar to claim 1 and is rejected for the same reasons. Claim 7 is directed towards “A system comprising: one or more processors (STURTIVANT [0088-0091]) “. 6. Regarding claim 14, it is similar to claim 1 and is rejected for the same reasons. Claim 14 is directed towards “A non-transitory computer readable medium comprising instructions that when executed by one or more processors (STURTIVANT [0088], also see claim 8 for use of term ‘non-transitory’) ”. 7. Regarding claim 4, wherein the combination, Krishnaraj teaches “ The method of claim 1, wherein the plurality of subtasks include one or more of: gathering user data, editing forms with the user data, generating a document, verifying identity of a user, creating user data, generating a profile based on the user data, updating user data, and deleting user data. ([0036] teaches that tasks can be business process tasks related to business data such as documents, order, forms, database records, email statements, and the like; and the tasks may be broken up into subtasks such that a subtask represents one of these data, and the data may pertain to a user) ”. 8. Regarding claims 10 and 17, they are similar to claim 4 and are rejected for the same reasons. 9. Regarding claim 5, the combination teaches “ The method of claim 1, wherein the response includes information associated with an error in execution of one or more subtasks (STURTIVANT [0052-0053] teaches the messaging service transmitting notifications in response to conditions such as “resource X has stopped responding” or something of the like such that it represents a failure. It also teaches data records being returned to the AP, data records being whether a process failed. [0079] teaches the API responding with status codes, such codes may indicate an error. Krishnaraj [0145] teaches an error queue that holds messages indicating errors encountered when processing) ”. 10. Regarding claims 11 and 18, they are similar to claim 5 and are rejected for the same reasons. 11. Regarding claim 6, wherein the combination, STURTIVANT teaches “ The method of claim 1, further comprising: receiving a request from the messaging application to execute a failed subtask ([0075-0076] teaches that the automation data processor can commit processed message offsets back to the data pipeline to achieve “at-least-once” processing, and in case of failure, may restart from a last committed point such that the AP may re-request the failed task to be executed, and it will start processing at the last saved point) ” . 12. Regarding claims 12 and 19, they are similar to claim 6 and are rejected for the same reasons. 13. Regarding claim 13, wherein the combination, STURTIVANT teaches “The system of claim 7, wherein the one or more processors receive the multi-threaded task request from the messaging application using one or more of: a publish-subscribe model of communication or by streaming ([0032]) ”. 14. Regarding claim 20, it is similar to claim 13 and is rejected for the same reasons . 07-21-aia AIA 15. Claim s 2, 8, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over STURTIVANT and Krishnaraj as applied to claims 1, 7, and 14 above, and in further view of Massoudian et al. Pub. No. US 2025/0028743 A1 (hereafter Massoudian) . 16. Regarding claim 2, the combination does touch on converting an input document into a Unicode text document (Krishnaraj [0153]), though it is not formatted. Massoudian teaches converting a user’s prompt into JSON format such that it teaches the limitation “ The method of claim 1, further comprising: converting the multi-threaded task request into a text format ([0058] teaches a user prompt to perform a task, and converting that prompt into JSON format or any suitable format) ”. It would have been obvious to a person of ordinary skill in the art before the effective filing date to combine the teachings of Massoudian to the combination of STURTIVANT and Krishnaraj, for converting a user prompt for performing a task into a suitable text format. A person having ordinary skill in the art would have been motivated to make this combination in order to standardize data exchange, such as achieving API compatibility, enabling communication with webservices. 17. Regarding claims 8 and 15, they are similar to claim 2 and are rejected for the same reasons . 07-21-aia AIA 18. Claim s 3, 9, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over STURTIVANT and Krishnaraj as applied to claims 1, 7, and 14 above, and in further view of Khemani et al. Pub. No. US 2024/0112196 A1 (hereafter Khemani) . 19. Regarding claim 3, the combination does not explicitly teach polling the messaging application for additional task requests. Khemani teaches periodic polling by a bot such that it teaches the limitation “The method of claim 1, further comprising: polling the messaging application for an additional multi-threaded task request ([0117-0127] teaches receiving updates in respect of a ticket and social media platform; the issue management system polls the issue tracking system (ITS) for any additional message or comments are made with respect to that ticket or message. It also notes that the message may be receive in response to a polling message sent by the bot) ”. It would have been obvious to a person of ordinary skill in the art before the effective filing date to combine the teachings of Khemani to the combination of STURTIVANT and Krishnaraj, to poll the messaging application for additional multi-threaded requests. A person having ordinary skill in the art would have been motivated to make this combination in order to allow updates for a request; updates may include additional information to a request, retrying a task that may have failed, a task that may require user approval and information, status updates, or discover a new thread of tasks to work on. 20. Regarding claims 9 and 16, they are similar to claim 3 and are rejected for the same reasons. Conclusion 21. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRANDON A NGUYEN whose telephone number is (571)272-6074. The examiner can normally be reached Mon-Fri (10am-6pm). 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, Aimee Li can be reached at (571) 272-4169. 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. /BRANDON NGUYEN/Examiner, Art Unit 2195 /Aimee Li/Supervisory Patent Examiner, Art Unit 2195 Application/Control Number: 18/603,981 Page 2 Art Unit: 2195 Application/Control Number: 18/603,981 Page 3 Art Unit: 2195 Application/Control Number: 18/603,981 Page 4 Art Unit: 2195 Application/Control Number: 18/603,981 Page 5 Art Unit: 2195 Application/Control Number: 18/603,981 Page 6 Art Unit: 2195 Application/Control Number: 18/603,981 Page 7 Art Unit: 2195 Application/Control Number: 18/603,981 Page 8 Art Unit: 2195
Prosecution Insights