Prosecution Insights
Last updated: July 17, 2026
Application No. 19/206,309

DIGITAL PROCESSING SYSTEMS AND METHODS FOR PERFORMING DYNAMIC TICKET ASSIGNMENT OPERATIONS BASED ON CONTINUOUSLY CHANGING INPUT AND OUTPUT PARAMETERS

Non-Final OA §101§103
Filed
May 13, 2025
Priority
Dec 30, 2022 — continuation of 18/148,817
Examiner
LABOGIN, DORETHEA L
Art Unit
3624
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
Monday Com Ltd.
OA Round
1 (Non-Final)
14%
Grant Probability
At Risk
1-2
OA Rounds
2y 1m
Est. Remaining
29%
With Interview

Examiner Intelligence

Grants only 14% of cases
14%
Career Allowance Rate
24 granted / 178 resolved
-38.5% vs TC avg
Strong +16% interview lift
Without
With
+15.7%
Interview Lift
resolved cases with interview
Typical timeline
3y 3m
Avg Prosecution
27 currently pending
Career history
213
Total Applications
across all art units

Statute-Specific Performance

§101
5.3%
-34.7% vs TC avg
§103
87.5%
+47.5% vs TC avg
§102
7.3%
-32.7% vs TC avg
Black line = Tech Center average estimate • Based on career data from 178 resolved cases

Office Action

§101 §103
DETAILED ACTION Status of the Application This Non-Final Office Action is in response to Application Serial 19/206,309. This Application is a continuation of Application 18/148,817. The claims 1-20 are pending. Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. Information Disclosure Statement The information disclosure statements (IDS) submitted on February 25, 2026 and May 13, 2025 were filed is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements is/are being considered by the examiner. Applicant submitted three IDSs. Two are mail dated February 25, 2026. One is mail dated May 13, 2025. 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-10 are manufacture. Claims 11-15 are process. Claims 16-20 are machine. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim 1 (and similarly claim 11 and claim 16) recite, “… initially receiving in … from a plurality of different sources, a first plurality of ticket requests, wherein each of the first plurality of ticket requests includes first ticket factor information including a first priority factor, a first skill factor, a first language indicator, and a first response time factor; receiving in … , resource information about a plurality of available resources, wherein the resource information for each of the plurality of resources includes resource language information, resource schedule information, resource capacity information, and resource skill information; during a first time window following initial receipt of the first plurality of ticket requests, determining a first plurality of preferred matches between the first plurality of ticket requests and the plurality of available resources; assigning the first plurality of ticket requests based on the first plurality of preferred matches; subsequently receiving …, a second plurality of ticket requests, wherein each of the second plurality of ticket requests includes second ticket factor information including a second priority factor, a second skill factor, a second language indicator, and a second response time factor; during a second time window following subsequent receipt of the second plurality of ticket requests, determining a second plurality of preferred matches between the second plurality of ticket requests and the plurality of available resources; assigning the second plurality of ticket requests based on the second plurality of preferred matches; receiving … updates of ticket factor information for some of the received first and second pluralities of ticket requests, and updating ticket requests based on the received updates; receiving … for at least some plurality of available resources, updates to at least one of the resource schedule information or the resource capacity information, and updating the resource information based on the received updates; during a third time window following the second time window, determining a third plurality of preferred matches between: at least one of the first plurality of ticket requests, the second plurality ticket requests, or the updated ticket requests; and at least one of the available resources or the updated available resources; assigning at least one of the first ticket requests, second ticket requests, or the updated ticket requests, based on the third plurality of preferred matches.” Claims 1-20 in view of the claim limitations, are directed to the abstract idea of assigning work tickets to available resources/people which is a commercial interactions (including marketing or sales activities or behaviors business relations) and managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules or instruction). The limitations recite commercial activities and business activities, and thus, the claims recite certain methods of organizing human activity. Furthermore, the claims recite determining a first plurality of preferred matches between the first plurality of ticket requests and the plurality of available resources; assigning the first plurality of ticket requests based on the first plurality of preferred matches. Correlating and Matching tickets with available resources are concepts that can be performed in the human mind (including an observation, evaluation, judgement, opinion). The claims recite mental concepts, and therefore, the claims recite an abstract concept that is a mental concept. Accordingly, the claims are recite certain methods of organizing human activity and mental processes, which is an abstract idea. The claims recite abstract concepts, so the claims are directed to a judicial exception under the first prong of Step 2A. This judicial exception are not integrated into a practical application under the second prong of Step 2A. In particular, the claims recite the additional elements beyond the recited abstract idea of, “A non-transitory computer readable medium containing instructions that when executed by the at least one processor cause the at least one processor to perform dynamic ticket assignment operations based on continuously changing input and output parameters, the operations comprising: ”,“a backlog data structure”, “a resource availability data structure”, in claim 1 (and similarly claim 11, and claim 16); however, when viewed as an ordered combination, and pursuant to the broadest reasonable interpretation, each of the additional elements are computing elements recite adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer or merely uses a computer as a tool to perform an abstract idea. See MPEP 2106.05 (f). The dependent claims do not recite additional elements beyond what those that are recited in the independent claims. Regarding an improvement, the claims pursuant to the broadest reasonable interpretation are optimizing the abstract concept of assigning work tickets to available resources/people and matching ticket factors to the resources. The claims 6, 7, 13 and 14 merely recite a potential improvement. Examiner submits, Applicant should clarify the optimization and improvement steps as supported in the specification. Examiner points Applicant to the instant specification [061]. The claims are not integrated into a practical application at step 2A prong two. At Step 2B, the claims when considered as a whole do not amount to significantly more. The claims are applying a computer to conduct the abstract concept. See MPEP 2106.05 (f).The claims broadly recite an improvement and optimization. Reciting an improvement absent limitations that technically reflect improvement in technology or any other technology or technical field does not amount to significantly more. At step 2B, it is MPEP 2106.05 (d) – Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information). In this Application, the claims recite … subsequently receiving in the backlog data structure, a second plurality of ticket requests, wherein each of the second plurality of ticket requests includes second ticket factor information including a second priority factor, a second skill factor, a second language indicator, and a second response time factor; during a second time window following subsequent receipt of the second plurality of ticket requests, determining a second plurality of preferred matches between the second plurality of ticket requests and the plurality of available resources; assigning the second plurality of ticket requests based on the second plurality of preferred matches; receiving in the backlog data structure, updates of ticket factor information for some of the received first and second pluralities of ticket requests, and updating ticket requests based on the received updates; receiving in the resource availability data structure for at least some plurality of available resources, updates to at least one of the resource schedule information or the resource capacity information, and updating the resource information based on the received updates … these limitations are performing the same functions that are completed when the first ticket is received and assigned. Examiner concludes that the additional elements in combination fail to amount to significantly more than the abstract idea based on findings that each element merely performs the same function (s) in combination as each element performs separately. The claim is not patent eligible. Thus, taken alone, the additional elements do not amount to significantly more than the above-identified exception (the abstract idea). Looking at the limitation as an ordered combination adds nothing that is not already present when looking at the elements taken individually. Dependent claims 2-10 further narrow the abstract idea of independent claim 1. Dependent claims 12-15 further narrow the abstract idea of independent claim 11. Dependent claims 17-20 further narrow the abstract idea of independent claim 16. The claims 1-20 are not patent eligible. Moreover, aside from the aforementioned additional elements, the remaining elements of dependent claims 2-10 & 12-15 & 17-20 do not transform the recited abstract idea into a patent eligible invention because these claims merely recite further limitations that provide no more than simply narrowing the recited abstract idea. Since there are no limitations in these claims that transform the exception into a patent eligible application such that these claims amount to significantly more than the exception itself, claims 1-20 are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter. Claim Rejections - 35 USC § 103 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 text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action. 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. Claim(s) 1, 2, 3, 9, 10, 11, 12, 13, 16, 17, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gupta (US 12,034,613 B2) in view of in further view of Kadioglu (US 2017/0,277,620 A1). Regarding Claim 1 (under similarly Claim 11 and claim 16), A non-transitory computer readable medium containing instructions that when executed by the at least one processor cause the at least one processor to perform dynamic ticket assignment operations based on continuously changing input and output parameters, the operations comprising: Gupta Figure 4 and the associated text. Gupta teaches in an example, the smart routing system initially identifies tickets in the queue. If the ticket is a pharmacy ticket, originating from a Middle East client, the smart routing system can narrow the destination down to the correct support team. For example, a pharmacy support team in Bangalore may be responsible for pharmacy tickets for Middle East clients. Further, the Bangalore pharmacy team may have five or six associates, so the smart routing system has to determine which of the five or six associates in the Bangalore pharmacy team should receive the ticket., Gupta [column 4 lines 8-11]. Gupta teaches identification component 308 may associate a severity of the ticket or how long a ticket has been pending (backlog ) with a particular support team, or prevents the ticket from being automatically routed altogether by the smart routing system. Gupta [Column 11 lines 1- 25], [column 11 lines 61-63]. initially receiving in a backlog data structure from a plurality of different sources, a first plurality of ticket requests, wherein each of the first plurality of ticket requests includes first ticket factor information including a first priority factor, a first skill factor, a first language indicator, and a first response time factor; Gupta teaches a batch job is run every 5 minutes … identify newly logged tickets by querying a ticket database (a backlog data structure) corresponding to a ticket systems (different sources) … identifying which geographic locations (resource, factor) are able or eligible to handle a particular ticket… system may also identify which associates (resource) have the required knowledge (skills) to work on a particular ticket. Gupta [column 3 lines 20-35] Gupta discloses tickets are routed by specified keywords found in the summary or description. If a keyword is not found, the ticket might route to the United States support team or a primary support hub. Gupta [column 3 lines 40-46]. Gupta teaches some associates may be on shift and some may be off shift. Some associates may not be qualified or experience to resolve a pharmacy solution support category ticket or an incident type ticket. Moreover, some associates may be on vacation. Accordingly, as shown at step 840, the associate availability indicates that of the six associates in the Bangalore support hub, three are available to resolve the ticket. Gupta [Column 13 lines 10-35]. receiving in a resource availability data structure, resource information about a plurality of available resources, wherein the resource information for each of the plurality of resources includes resource language information, resource schedule information, resource capacity information, and resource skill information; Same as above Gupta [column 3 lines 20-35] and Gupta [column 3 lines 40-46]. Gupta teaches some associates may be on vacation. Accordingly, as shown at step 840, the associate availability indicates that of the six associates in the Bangalore support hub, three are available to resolve the ticket. Finally, at step 850 queue balancing indicates that one associate has a smaller queue, which may be determined by a simple count of tickets in each associate's queue, or may be determined by a more complex analysis of the type, number, and complexity of tickets in each associate's queue. Once the associate with the smallest queue is identified, the ticket can be routed to that associate. Gupta [Column 13 lines 10-35]. during a first time window following initial receipt of the first plurality of ticket requests, determining a first plurality of preferred matches between the first plurality of ticket requests and the plurality of available resources; assigning the first plurality of ticket requests based on the first plurality of preferred matches; Gupta [Column 13 lines 10-35]. subsequently receiving in the backlog data structure, a second plurality of ticket requests, wherein each of the second plurality of ticket requests includes second ticket factor information including a second priority factor, a second skill factor, a second language indicator, and a second response time factor; during a second time window following subsequent receipt of the second plurality of ticket requests, determining a second plurality of preferred matches between the second plurality of ticket requests and the plurality of available resources; assigning the second plurality of ticket requests based on the second plurality of preferred matches; receiving in the backlog data structure, updates of ticket factor information for some of the received first and second pluralities of ticket requests, and updating ticket requests based on the received updates; receiving in the resource availability data structure for at least some plurality of available resources, updates to at least one of the resource schedule information or the resource capacity information, and updating the resource information based on the received updates; Same as above. Gupta matches tickets that are in the queue with associates. Assigning a ticket, then routing a ticket to an associate is an update. Gupta [column 11 lines 1- 25], [column 11 lines 61-63], [column 4 lines 8-11], [column 13 lines 10-35], [column 3 lines 20-35], [column 3 lines 40-46]. during a third time window following the second time window, determining a third plurality of preferred matches between: at least one of the first plurality of ticket requests, the second plurality ticket requests, or the updated ticket requests; and at least one of the available resources or the updated available resources; and assigning at least one of the first ticket requests, second ticket requests, or the updated ticket requests, based on the third plurality of preferred matches. See above. Gupta matches tickets that are in the queue with associates. Assigning a ticket, then routing a ticket to an associate is an update. Gupta [column 11 lines 1- 25], [column 11 lines 61-63], [column 4 lines 8-11], [column 13 lines 10-35], [column 3 lines 20-35], [column 3 lines 40-46]. Gupta Figure 8 and Figure 4 and the associated text and Gupta teaches an iterative process to identify the most appropriate associate on the most appropriate support team for assigning the ticket., Gupta [abstract], [column 1 lines 55 -60]. Examiner submits these three limitations are Markush limitations. Examiner notes a Markush statement for each of the clauses could be appropriate. Applicant is encouraged to claim an embodiment as supported by the instant specification . Gupta discloses once the associate with the smallest queue and skills is identified, the ticket can be routed to that associate, and thus, Gupta teaches updated ticket requests. Claim 1 is a "Markush" claim recites a list of alternatively useable members. In re Harnisch, 631 F.2d 716, 719-20, 206 USPQ 300, 303 (CCPA 1980); Ex parte Markush, 1925 Dec. ... The listing of specified alternatives within a Markush claim is referred to as a Markush group or a Markush grouping. ... Cir. 2003)(citing to several sources that describe Markush groups)- See MPEP 706.03 Examiner further relies on Kadioglu to teach: … backlog structure and resource data structure ... Kadioglu discloses the request data structure 300 (a backlog structure) of FIG. 3,, Kadioglu [037], [Figure 3]. Kadioglu discloses… session … request data. , state parameters., Kadioglu [Figure 5] and an assignment data structure 400 . Kadiolugu discloses iterative approach allows for the modeling of the dynamic and real time nature of a resource management. Kadioglu [009]. Gupta provides a real-time routing system that helps reduce the wait time on the assignment of client logged support requests. Kadiogu generates an assignment solution between resources and requests as represented by the resource data and the request data. It would have been obvious to combine before the effective filling date, identifying newly logged tickets by querying a ticket database corresponding to a ticket system, as taught by Gupta, with request data held in a request structure, as taught by Kadiogu, so the call may have a history if knowing approximately how may requests that the business receives. Kadiolgu [024]. Regarding Claim 2, [and similarly claim 12 and claim 17] The non-transitory computer readable medium of claim 1, wherein at least one of the first, second, or third plurality of preferred matches are determined using one or more stored rules correlating ticket factor information with resource information. See above. Gupta [Column 13 lines 10-35] matches the ticket to an available resource. Gupta discloses once the associate with the smallest queue is identified, the ticket can be routed to that associate, and thus, Gupta teaches the first plurality of preferred matches. Claim 2 is a "Markush" claim recites a list of alternatively useable members. In re Harnisch, 631 F.2d 716, 719-20, 206 USPQ 300, 303 (CCPA 1980); Ex parte Markush, 1925 Dec. ... The listing of specified alternatives within a Markush claim is referred to as a Markush group or a Markush grouping. ... Cir. 2003)(citing to several sources that describe Markush groups)- See MPEP 706.03. Regarding Claim 3, [and similarly claim 13 and claim 18] The non-transitory computer readable medium of claim 2, wherein at least one of the stored rules is dynamic and changes based on a criteria. See above. Gupta [Column 13 lines 10-35] matches the ticket to an available resource. Moving the ticket from a queue to an available resource is change in the criteria. Gupta teaches if the ticket is predicted to be a change ticket, the earlier support layers may be bypassed and the ticket may be directly routed to the change team., Gupta [column 4 lines 3-6]. Gupta discloses tickets are routed by specified keywords found in the summary or description. If a keyword is not found, the ticket might route to the United States support team or a primary support hub., Gupta [column 3 lines 40-46]. Regarding Claim 9, The non-transitory computer readable medium of claim 1, wherein the backlog data structure and resource availability data structure are stored in a common location. Gupta Figure 1 – item 108, item 102 teach remote computers. The remote computers 108 might be located at a variety of locations in a medical or research environment, including clinical laboratories (e.g., molecular diagnostic laboratories), hospitals and other inpatient settings, ambulatory settings and Figure 2. Gupta teaches the present invention might be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. … In a distributed computing environment, program modules might be located in association with local and/or remote computer storage media (e.g., memory storage devices). Gupta [column 5 lines 45-66] Examiner further relies on Kadioglu to teach: … backlog structure and resource data structure ... Kadioglu discloses the request data structure 300 (a backlog structure) of FIG. 3,, Kadioglu [037], [Figure 3]. Kadioglu discloses… session … request data. , state parameters., Kadioglu [Figure 5] and an assignment data structure 400 . Kadiolugu discloses iterative approach allows for the modeling of the dynamic and real time nature of a resource management. Kadioglu [009]. Gupta provides a real-time routing system that helps reduce the wait time on the assignment of client logged support requests. Kadiogu generates an assignment solution between resources and requests as represented by the resource data and the request data. It would have been obvious to combine before the effective filling date, identifying newly logged tickets by querying a ticket database corresponding to a ticket system, as taught by Gupta, with request data held in a request structure, as taught by Kadiogu, so the call may have a history if knowing approximately how may requests that the business receives. Kadiolgu [024]. Regarding Claim 10, The non-transitory computer readable medium of claim 1, wherein the backlog data structure and resource data structure are stored in different locations. Gupta Figure 1 – item 108, item 102 teach remote computers. The remote computers 108 might be located at a variety of locations in a medical or research environment, including clinical laboratories (e.g., molecular diagnostic laboratories), hospitals and other inpatient settings, ambulatory settings. and Figure 2. Gupta teaches the present invention might be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. … In a distributed computing environment, program modules might be located in association with local and/or remote computer storage media (e.g., memory storage devices). Gupta [column 5 lines 45-66] Examiner further relies on Kadioglu to teach: … backlog structure and resource data structure ... Kadioglu discloses the request data structure 300 (a backlog structure) of FIG. 3,, Kadioglu [037], [Figure 3]. Kadioglu discloses… session … request data. , state parameters., Kadioglu [Figure 5] and an assignment data structure 400 . Kadiolugu discloses iterative approach allows for the modeling of the dynamic and real time nature of a resource management. Kadioglu [009]. Gupta provides a real-time routing system that helps reduce the wait time on the assignment of client logged support requests. Kadiogu generates an assignment solution between resources and requests as represented by the resource data and the request data. It would have been obvious to combine before the effective filling date, identifying newly logged tickets by querying a ticket database corresponding to a ticket system, as taught by Gupta, with distributed computing environments where tasks are performed by remote processing devices, as taught by Kadiogu, to properly handle the requests (i.e., to achieve the desired performance). Kadiolgu [024]. Claim(s) 4, 5, 6, 7, 8, 14, 15, 19, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gupta (US 12,034,613 B2) in view of Kadioglu (US 2017/0,277,620 A1) and in further view of Shukla (US 2016/0,283,889 A1). Regarding Claim 4, The non-transitory computer readable medium of claim 1, wherein the criteria is selectable via a user interface. Although Gupta teaches user devices and a support team in Figure 2, Examiner relies on Shukla to teaches criteria is selectable via a user interface. Shukla Figure 5B and the associated text teach a ticket solver solution and interface.; Shukla discloses the ticket solver device 210 may tailor a user interface, associated with the ticket solver system, based on identifying a particular user. Shukla [032], [048]. Shukla teaches the ticket solver system may analyze information included in the ticket resolution history to optimize the subject matter experts' use of the ticket solver system (e.g., by identifying likely issues, optimizations, and/or suggested modifications associated with technical solution workflows based on information associated with past tickets, to provide the subject matter experts with assistance. Shukla [014]-[015], [Figure 5B], [054]. Gupta provides a real-time routing system that helps reduce the wait time on the assignment of client logged support requests. Shukla identifies a ticket associated with an issue, a user associated with resolving the issue, and a particular business process including a particular business process step associated with the issue. It would have been obvious to combine before the effective filling date, identifying newly logged tickets by querying a ticket database corresponding to a ticket system, as taught by Gupta, with analyzing information included in the ticket resolution history to optimize the subject matter experts' use of the ticket solver system (e.g., by identifying likely issues, optimizations, and/or suggested modifications associated with technical solution workflows based on information associated with past tickets, as taught by Shukla to assist users with identifying common causes of and solutions to clients' issues and may likewise identify knowledgebase deficiencies. Shukla [012]. Regarding Claim 5, The non-transitory computer readable medium of claim 1, wherein at least one of the first plurality of preferred matches, the second plurality of preferred matches, or the third plurality of preferred matches is an optimization of the best match between ticket requests and available resources. See Gupta Figure 2 and Shukla teaches updating the resolution history, ticket solver device 210 may optimize the operation of the ticket solver system by assisting a user, of user device 220, to track the progress of resolving a ticket, and/or modifying a knowledge associated with the ticket solver system, Shukla [048], [014]-[015], [Figure 5B], [054]. Gupta provides a real-time routing system that helps reduce the wait time on the assignment of client logged support requests. Shukla identifies a ticket associated with an issue, a user associated with resolving the issue, and a particular business process including a particular business process step associated with the issue. It would have been obvious to combine before the effective filling date, identifying newly logged tickets by querying a ticket database corresponding to a ticket system, as taught by Gupta, with analyzing information included in the ticket resolution history to optimize the subject matter experts' use of the ticket solver system (e.g., by identifying likely issues, optimizations, and/or suggested modifications associated with technical solution workflows based on information associated with past tickets, as taught by Shukla to assist users with identifying common causes of and solutions to clients' issues and may likewise identify knowledgebase deficiencies. Shukla [012]. Gupta discloses once the associate that matches ticket skills has been identified and the associate has the smallest queue is identified then the ticket can be routed to that associate, and thus, Gupta teaches the first plurality of preferred matches. Claim 5 is a "Markush" claim recites a list of alternatively useable members. In re Harnisch, 631 F.2d 716, 719-20, 206 USPQ 300, 303 (CCPA 1980); Ex parte Markush, 1925 Dec. ... The listing of specified alternatives within a Markush claim is referred to as a Markush group or a Markush grouping. ... Cir. 2003)(citing to several sources that describe Markush groups)- See MPEP 706.03 Regarding Claim 6, [and similarly claim 19] The non-transitory computer readable medium of claim 1, the operations further comprising running an optimization on one or more assigned ticket requests to identify a potential improvement. See Gupta Figure 2 and Shukla [048], [014]-[015], [Figure 5B], [054]. Gupta provides a real-time routing system that helps reduce the wait time on the assignment of client logged support requests. Shukla identifies a ticket associated with an issue, a user associated with resolving the issue, and a particular business process including a particular business process step associated with the issue. It would have been obvious to combine before the effective filling date, identifying newly logged tickets by querying a ticket database corresponding to a ticket system, as taught by Gupta, with analyzing information included in the ticket resolution history to optimize the subject matter experts' use of the ticket solver system (e.g., by identifying likely issues, optimizations, and/or suggested modifications associated with technical solution workflows based on information associated with past tickets, as taught by Shukla to assist users with identifying common causes of and solutions to clients' issues and may likewise identify knowledgebase deficiencies. Shukla [012]. Regarding Claim 7, [and similarly claim 20] The non-transitory computer readable medium of claim 6, the operations further comprising reassigning at least one previously assigned ticket request of the one or more assigned ticket requests based on the identified potential improvement. See above. Gupta [Column 13 lines 10-35] matches the ticket to an available resource Shukla [048], [014]-[015], [Figure 5B], [054]. Gupta provides a real-time routing system that helps reduce the wait time on the assignment of client logged support requests. Shukla identifies a ticket associated with an issue, a user associated with resolving the issue, and a particular business process including a particular business process step associated with the issue. It would have been obvious to combine before the effective filling date, identifying newly logged tickets by querying a ticket database corresponding to a ticket system, as taught by Gupta, with analyzing information included in the ticket resolution history to optimize the subject matter experts' use of the ticket solver system (e.g., by identifying likely issues, optimizations, and/or suggested modifications associated with technical solution workflows based on information associated with past tickets, as taught by Shukla to assist users with identifying common causes of and solutions to clients' issues and may likewise identify knowledgebase deficiencies. Shukla [012]. Regarding Claim 8, The non-transitory computer readable medium of claim 6, wherein previously assigned tickets already initiated are excluded from the optimization. See Gupta Figure 2. Gupta teaches based on the client that created the ticket, contractual or other reasons may necessitate that the ticket be excluded from the smart routing system. Similarly, the severity of the ticket (e.g., significant or high) may necessitate that the ticket be excluded from being routed by the smart routing system. Additionally, the pending time of the ticket may prevent the ticket from being routed by the smart routing system. If the ticket is not excluded by any of the filters, it is ready to proceed to the preparation phase, as shown at step 540. Gupta [column 12 lines 1-10]. Shukla further teaches a dashboard with resolved tickets and unresolved tickets. Shukla [062], [Figure 5D]. Gupta provides a real-time routing system that helps reduce the wait time on the assignment of client logged support requests. Shukla identifies a ticket associated with an issue, a user associated with resolving the issue, and a particular business process including a particular business process step associated with the issue. It would have been obvious to combine before the effective filling date, identifying newly logged tickets by querying a ticket database corresponding to a ticket system, as taught by Gupta, with analyzing information included in the ticket resolution history to optimize the subject matter experts' use of the ticket solver system (e.g., by identifying likely issues, optimizations, and/or suggested modifications associated with technical solution workflows based on information associated with past tickets, as taught by Shukla to assist users with identifying common causes of and solutions to clients' issues and may likewise identify knowledgebase deficiencies. Shukla [012]. Regarding Claim 14, The method of claim 11, further comprising running an optimization on at least one unassigned ticket request and at least one assigned ticket request to identify a potential improvement. Gupta Figure 2 and Shukla teaches the issue is associated with an error (identified as “Option 3”). Assume that, based on experiencing the issue, the client initiates a resolution process (e.g., by selecting a button labeled “Resolve”). Based on initiating the resolution process, user device 220-1 sends a request, including information associated with the error, to a ticket solver system (e.g., implemented by ticket solver device 210). Based on receiving the request and the information therein, ticket solver device 210 identifies a user (e.g., a user account associated with an automated problem solver), creates a new ticket, and identifies a business process workflow associated with the client's use of the software application (e.g., “Process 1”). Assume that ticket solver device 210 sends, to user device 220-1, a response, including information associated with selecting a business process workflow step from Process 1., Shukla [052], [Figure 5A]. Regarding Claim 15, The method of claim 14, further comprising reassigning at least one previously assigned ticket request based on the identified potential improvement. See Gupta Figure 2 and Shukla teaches a dashboard with resolved tickets and unresolved tickets. Shukla [062], [Figure 5D]. Gupta provides a real-time routing system that helps reduce the wait time on the assignment of client logged support requests. Shukla identifies a ticket associated with an issue, a user associated with resolving the issue, and a particular business process including a particular business process step associated with the issue. It would have been obvious to combine before the effective filling date, identifying newly logged tickets by querying a ticket database corresponding to a ticket system, as taught by Gupta, with analyzing information included in the ticket resolution history to optimize the subject matter experts' use of the ticket solver system (e.g., by identifying likely issues, optimizations, and/or suggested modifications associated with technical solution workflows based on information associated with past tickets, as taught by Shukla to assist users with identifying common causes of and solutions to clients' issues and may likewise identify knowledgebase deficiencies. Shukla [012]. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure Kleehammer (US 2015/0178657 A1) discloses incident resolution and administration sub-system 160 with one or more user interfaces and queue management. Rath (US 2021/0014136) teaches machine learning. Spire (US 8504679 B2) teaches managing execution of IT processes and a dashboard. Adrian (US 11514379 B2) teaches dashboard and interface. Any inquiry concerning this communication or earlier communications from the examiner should be directed to THEA LABOGIN whose telephone number is (571)272-9149. The examiner can normally be reached Monday -Friday, 8am-5pm. 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, Patricia Munson can be reached on 571-270- 5396. 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. /THEA LABOGIN/Examiner, Art Unit 3624
Read full office action

Prosecution Timeline

May 13, 2025
Application Filed
Jun 17, 2026
Non-Final Rejection mailed — §101, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12675782
Distributed Ledger Tracking of Robot Fleet Task Completion
3y 0m to grant Granted Jul 07, 2026
Patent 12586018
SYSTEM AND METHOD FOR CREATING A SERVICE INSTANCE
5y 2m to grant Granted Mar 24, 2026
Patent 12406218
DASHBOARD FOR MULTI SITE MANAGEMENT SYSTEM
2y 5m to grant Granted Sep 02, 2025
Patent 12321841
Unsupervised Cross-Domain Data Augmentation for Long-Document Based Prediction and Explanation
2y 7m to grant Granted Jun 03, 2025
Patent 12299609
DYNAMICALLY TRANSMITTING ONLINE MODE INVITATIONS TO PROVIDER DEVICES IN RESPONSE TO DETECTED CHANGES IN PROVIDER DEVICE EFFICIENCY
4y 9m to grant Granted May 13, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
14%
Grant Probability
29%
With Interview (+15.7%)
3y 3m (~2y 1m remaining)
Median Time to Grant
Low
PTA Risk
Based on 178 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month