DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This Action is in response to amendment/ remarks filed on 02/12/2026.
Independent claims 1 and 8-9 have been amended. Claims 16-20 are cancelled.
Claims 1-15 are presented for examination, and remain pending in this application.
Response to Arguments Regarding Claim Rejections - 35 USC § 101
The Applicant's amendment/ arguments, see page 13-15 of REMARKS, filed 02/12/2026, with respect to Claim Rejections - 35 USC § 101 have been fully considered and are persuasive. The inclusion of limitations previously recited in claim 19, describes a particular way to visualize/ display the user interface with details for each user account. The function was not rejected under 35 USC § 101, and overcomes the 35 USC § 101 rejection. As a result, the 35 USC § 101 rejections have been withdrawn.
Response to Arguments Regarding Claim Rejections - 35 USC § 103
The Applicant's amendment/ arguments, see page 15-16 of REMARKS, filed 02/12/2026, with respect to Claim Rejections - 35 USC § 103 have been fully considered and are persuasive. Dependent claim 19 (now cancelled) was previously objected to as allowable if rewritten to overcome the 35 USC § 101 and 35 USC § 112 rejections. The limitations previously recited in dependent claim 19 is now rolled-up into independent claims 1, and 8-9. As a result, the 35 USC § 103 rejections are withdrawn.
Response to Arguments Regarding Claim Rejections - 35 USC § 112
The Applicant's amendment/ arguments, see page 10-13 of REMARKS, filed 02/12/2026, with respect to Claim Rejections - 35 USC § 112 have been fully considered but they are not persuasive.
For context, examiner reproduces the concerning claim limitations as currently recited in amended independent claims 1 and 8-9, as follows:
wherein the severity score is further determined based on one or more of issue type, system types affected, elapsed time since ticket generation computed using the timestamp, or redundancy indicated by multiple ticket records associated with a same issue;
wherein automatically assigning includes updating the ticket record in the ticketing system to indicate assignment of the support ticket to the user account, and
displaying, via a user interface, a visualization indicating for each user account a current resolution capacity, an assigned workload, and a back-pressure metric derived from unresolved high-severity tickets.
In the response filed on 02/12/2026, applicant puts forth in substance that:
“System types affected. The disclosure expressly discusses system types affected (test vs production) as relevant to perceived/manageable back pressure and severity context:
"system types affected (e.g., ... test ... less acute than ... production)." See [0056]. Ticket issue data includes identifiers of the environment and resources. See [0061]. Thus, reciting "system types affected" as derived from environment/resource identifiers in the ticket record is supported.” (See page 11-12 of REMARKS, filed 02/12/2026).
Applicant’s relies on specification paragraphs [0056] and [0061] to show that reciting "system types affected" is supported by the original specification. Paragraphs [0056] and [0061] are reproduced below for ease.
[0056] In certain scenarios, a human operator may feel that a number of unresolved (i.e., open) support tickets is larger than can be managed when they view the number of closed tickets. However, this simple view of support tickets does not take into account severity, system types affected (e.g., an issue affecting a test system is less acute than an issue affecting a production system), redundancy (e.g., a ticket is generated for each of a thousand software container nodes on a relatively minor software update issue), combinations thereof, and the like.
[0061] At S320, a plurality of support tickets are received. In an embodiment, a support ticket is a data record, including a ticket type, a status indicator, issue data, a combination thereof, and the like. Issue data includes, according to an embodiment, an identifier of a resource, an identifier of a computing environment (e.g., an identifier of a VPC), an identifier of an issue, a CVE identifier, an identifier of a principal (e.g., identifier of a user account, a service account, a role, a user group, etc.), a time stamp, a severity, a risk score, a combination thereof, and the like. In an embodiment, the severity is qualitative, quantitative, a combination thereof, and the like.
Examiner concurs that there is literal support for "system types affected" in the specification (as highlighted above). However, examiner contends that mere recitation of literal term "system types affected" and/or recitation of “identifier of a computing environment” in specification paragraphs [0056] and [0061] respectively are taken out of context, and are completely unrelated to “determining the severity score” as currently claimed. For e.g., paragraph [0056] pertains to how a human operator may feel regarding a simple view of support tickets that does not take several factors into account. Similarly, paragraph [0061] pertains to step S320 of Fig.3, and is related to receiving a plurality of support tickets, rather than the following step S3320 of Fig.3 where severity score is actually determined. For this reason, the applicant’s argument is non-persuasive.
“Elapsed time since ticket generation. The disclosure discusses assignment considering "time since the ticket was opened." See [0021]. Time of generation is disclosed as a timestamp stored in the ticket record. See [0044]; see also [0061]. Thus, reciting elapsed time computed using the ticket timestamp is supported.” (See page 12 of REMARKS, filed 02/12/2026).
Again, examiner concurs that there is literal support for “elapsed time since ticket generation computed using the timestamp” in the specification. However, examiner contends that mere support for “elapsed time since ticket generation computed using the timestamp” in specification is taken out of context, and is completely unrelated to “determining the severity score” as currently claimed. For e.g., paragraph [0021] pertains to concept/step of assigning tickets. Similarly, paragraph [0061], as set for above, pertains to step S320 of Fig.3, and is related to receiving a plurality of support tickets, rather than the following step S3320 of Fig.3 where severity score is actually determined. In addition, [0044] discloses storing a ticket as a data record, and querying the ticketing system for ticket information. These paragraphs have nothing to do with “determining the severity score”. For this reason, the applicant’s argument is non-persuasive.
“Redundancy. Redundant tickets are expressly disclosed, including generation of "redundant tickets" for "the same issue detected at a first time... remains unresolved... detected at a second time." See [0034]. Redundancy is also expressly discussed as a factor contributing to perceived back pressure ("a ticket is generated for each of a thousand... nodes... "). See [0056]. Ticket issue data includes identifiers (resource/environment/issue identifiers) that support identifying redundancy across ticket records. See [0061]. The amended claims' "redundancy indicated by multiple ticket records associated with a same issue" is thus supported.” (See page 12 of REMARKS, filed 02/12/2026).
Again, examiner concurs that there may be support for “redundancy indicated by multiple ticket records associated with a same issue” in the specification. However, examiner contends that mere support for redundancy across ticket records in specification is taken out of context, and is completely unrelated to “determining the severity score” as currently claimed. For e.g., paragraph [0061], as set for above, pertains to step S320 of Fig.3, and is related to receiving a plurality of support tickets, rather than the following step S3320 of Fig.3 where severity score is actually determined. In addition, [0034] merely discloses cybersecurity monitoring system 120 generates redundant tickets. Furthermore, and as set for above, paragraph [0056] pertains to how a human operator may feel regarding a simple view of support tickets that does not take several factors into account. These paragraphs are unrelated to determining the severity score, and therefore have nothing to do with “determining the severity score”. For this reason, the applicant’s argument is non-persuasive.
“The disclosure teaches that the ticketing system can "assign a ticket to a user account," including based on IAM data and roles/groups. See [0032]-[0033]. The resolution server "is configured to access the ticketing system... determine... severity... determine... resolution capacity, and assign a support ticket to a user account... based on... severity... resolution capacity." See [0040]. Tickets are selected for assignment based on severity score. See [0066]. Given the disclosure that tickets are stored as data records [0061] and assignment is performed by the ticketing system / resolution server [0032], [0040], it is fully supported that assignment is implemented via updating ticket records to indicate the assignee.” (See page 12 of REMARKS, filed 02/12/2026).
The applicant’s argument pertains to the new limitation:
wherein automatically assigning includes updating the ticket record in the ticketing system to indicate assignment of the support ticket to the user account;
Examiner concurs that the specification discloses that tickets are stored as data records. The examiner also concurs that the specification discloses assignment is performed by the ticketing system / resolution server. However, examiner contends that given these disclosures, the specification supports “updating ticket records to indicate the assignment/ assignee” as currently claimed. Storing ticket as data records and ticket assignment are related but distinct features, and so is “updating the ticket record in the ticketing system to indicate assignment”. There are multiple ways to perform ticket assignment, as readily known in the art, and existence of one of these features in an invention does not necessarily/ inherently teach existence of other feature(s). In addition, the disclosed data record and/or issue data of support ticket does not even include assignment/ assignee field (see [0061]). It would therefore be improper for one of ordinary skill to conclude that assignment is explicitly/ exclusively implemented via updating ticket records even when given that the disclosure supports that tickets are stored as data records and assignment is performed by some disclosed system/ server. For this reason, the applicant’s argument is non-persuasive.
“Visualization of resolution capacity is explicitly disclosed in the Summary as an implementation feature: "generating a visualization of the resolution capacity." See [0010]. Back pressure is expressly defined as relating to open/unresolved tickets as compared to resolved tickets for a user/account/group. See [0055]-[0056]. Severity-based selection and the notion of "high severity" tickets is disclosed. See [0066]. Capacity per user/account/group is disclosed. See [0039], [0060]. Assignment to a user account is disclosed, which inherently defines an "assigned workload" as the set/number of tickets assigned to that account. See [0032], [0040], [0065].
Accordingly, the rolled-in visualization of current resolution capacity, assigned workload, and a back-pressure metric derived from unresolved high-severity tickets is supported by (i) the explicit disclosure of visualization of capacity [0010], (ii) the express definition of back pressure based on unresolved/open tickets [0055]-[0056] combined with severity scoring/selection [0063]-[0066], and (iii) the disclosed per-account capacity and assignment operations [0039]-[0040], [0060], [0065]-[0066].
For these reasons, amended claims 1, 8, and 9 are fully supported by the as-filed disclosure and do not introduce new matter. The prior §112(a) written-description rejection should therefore be withdrawn.” (See page 13 of REMARKS, filed 02/12/2026).
Examiner concurs that there may be support for “generating a visualization of the resolution capacity” in the specification at paragraph [0010]. However, examiner contends that there is enough in the disclosure to conclude that the visualization is also “indicating for each user account an assigned workload, and a back-pressure metric derived from unresolved high-severity tickets” as currently claimed. For e.g., knowledge of open/unresolved tickets as compared to resolved tickets”, “severity-based selection” an/or disclosure of “capacity per user/account/group” does not always translate to having a user interface that displays assigned workload, and a back-pressure metric, whether per account or otherwise. For this reason, the applicant’s argument is non-persuasive.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1 and 8-9 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding independent claims 1 and 8-9, the claims, as currently amended, recite:
“wherein the severity score is further determined based on one or more of issue type, system types affected, elapsed time since ticket generation computed using the timestamp, or redundancy indicated by multiple ticket records associated with a same issue;
wherein automatically assigning includes updating the ticket record in the ticketing system to indicate assignment of the support ticket to the user account, and
displaying, via a user interface, a visualization indicating for each user account a current resolution capacity, an assigned workload, and a back-pressure metric derived from unresolved high-severity tickets”.
Regarding the limitation “determining the severity score based on system types affected”, Applicant indicated that the paragraphs [0056] and [0061] describing Fig. 3 (S320) disclose the limitation (see page 11-12 of Remarks - 02/12/2026). However, as set forth above, paragraph [0056] pertains to how a human operator may feel regarding a simple view of support tickets that does not take several factors into account. Similarly, specification paragraph [0061] pertains to step S320, and is therefore related to receiving a plurality of support tickets step of claim 1 (and not related to the above limitation). Step S3320 of Fig.3 is rather where severity score is actually determined.
Regarding the limitation “determining the severity score based on elapsed time since ticket generation computed using the timestamp”, Applicant indicated that the paragraphs [0021], [0044] and [0061] describing Fig. 3 (S320) disclose the limitation (see page 12 of Remarks - 02/12/2026). However, and as set forth above, specification paragraph [0061] pertains to step S320, and is therefore related to receiving a plurality of support tickets step of claim 1 (and not related to the above limitation). Step S3320 of Fig.3 is rather where severity score is actually determined. In addition, [0044] discloses storing a ticket as a data record, and querying the ticketing system for ticket information. Also, paragraph [0021] pertains to concept/step of assigning tickets. These paragraphs have nothing to do with “determining the severity score”.
Regarding the limitation “determining the severity score based on redundancy indicated by multiple ticket records associated with a same issue”, Applicant indicated that the paragraphs [0034], [0056] and [0061] describing Fig. 3 (S320) disclose the limitation (see page 12 of Remarks - 02/12/2026). However, paragraph [0056] pertains to how a human operator may feel regarding a simple view of support tickets that does not take several factors into account. Similarly, and as set forth above, specification paragraph [0061] pertains to step S320, and is therefore related to receiving a plurality of support tickets step of claim 1 (and not related to the above limitation). Step S3320 of Fig.3 is rather where severity score is actually determined. In addition, [0034] merely discloses cybersecurity monitoring system 120 generates redundant tickets. These paragraphs have nothing to do with “determining the severity score”.
Regarding the limitation “wherein automatically assigning includes updating the ticket record in the ticketing system to indicate assignment of the support ticket to the user account”, examiner contends that the specification supports “updating ticket records to indicate the assignment/ assignee” as currently claimed. The disclosed data record and/or issue data of support ticket does not include assignment/ assignee field (see [0061]). It would therefore be improper for one of ordinary skill to conclude that assignment is explicitly/ exclusively implemented via updating ticket records even when given that the disclosure supports that tickets are stored as data records and assignment is performed by some disclosed system/ server.
Regarding the limitation “displaying, via a user interface, a visualization indicating for each user account a current resolution capacity, an assigned workload, and a back-pressure metric derived from unresolved high-severity tickets”, Examiner concurs that there may be support for “generating a visualization of the resolution capacity” in the specification at paragraph [0010]. However, examiner contends that there is enough in the disclosure to conclude that the visualization is also inherently “indicating for each user account an assigned workload, and a back-pressure metric derived from unresolved high-severity tickets” as currently claimed.
Upon review of the rest of the applicant’s original specification and the accompanying drawing, examiner concludes that the application’s disclosure does not clearly support:
“wherein the severity score is further determined based on one or more of issue type, system types affected, elapsed time since ticket generation computed using the timestamp, or redundancy indicated by multiple ticket records associated with a same issue;
wherein automatically assigning includes updating the ticket record in the ticketing system to indicate assignment of the support ticket to the user account, and
displaying, via a user interface, a visualization indicating for each user account a current resolution capacity, an assigned workload, and a back-pressure metric derived from unresolved high-severity tickets”, as highlighted above. Nor does it elaborate on how the data aggregation actually happens.
Moreover, applicant asserts that the one or more data such as “issue type, system type affected, elapsed time since ticket generation, redundancy of the issue, or customer sentiment” are being obtained “from the cybersecurity monitoring system, the IAM server, and the ticketing system”. Since the original specification fails to disclose the claimed limitation, and the applicant fails to explicitly point where support lies for such limitation, Examiner deems that the amended claims fail to comply with the written description requirement as it contains subject matter which was not described in the original specification filed on 01/10/2024 (NEW MATTER).
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claims 2 and 10 are rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
Claims 2 and 10 depends from independent claims 1 and 9 respectively, and recite the limitation “generating a visualization of the resolution capacity”. However, the respective independent claims already recite “displaying, via a user interface, a visualization indicating for each user account a current resolution capacity”. Therefore, the dependent claims 2 and 10 are failing to further limit the subject matter of the claim upon which the depend respectively.
Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
Allowable Subject Matter
Claims 1, 3-9 and 11-15 would be allowable if rewritten to overcome the rejection(s) under 35 USC 112(b) or 35 U.S.C. 112 (pre-AIA ), 2nd paragraph, set forth in this Office action and to include all of the limitations of the base claim and any intervening claims.
Additional References
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Read (US 20150112771 A1) discloses assigning, using the one or more computers, a respective weight value for each of the plurality of component data, including runtime behavioral data comprising performed workflow data.
JOHNSON et al. (US 20240320574 A1) teaches a system that can automatically update the present capacity status and the connecting parameter of the one or more service channels based on the determination that the present capacity status is above the threshold capacity status.
Ganesan et al. (US 20240363246 A1) iterates over symptom data, normalization, aggregation, and aggregating baseline scores that represents the average severity of symptoms experienced.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 SANDARVA KHANAL whose telephone number is (571)272-8107. The examiner can normally be reached MON-FRI, 0800-1700.
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, Kamal B Divecha can be reached at 571-272-5863. 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.
/SANDARVA KHANAL/Primary Examiner, Art Unit 2453