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 .
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on June 22, 2026 has been entered.
Claims 1, 3, and 5-20 are pending. Claims 1, 11 and 18 are amended. Claims 2 and 4 have been cancelled.
Response to Arguments
Applicant’s arguments with respect to claims 1, 3, and 5-20, as amended, been considered but are not persuasive.
Applicant argues that Sachan/Turkkan does not teach that the processing of the incident ticket framework applies to a new enterprise application incident ticket. However, Examiner respectfully disagrees. Sachan discloses that the incident creation and routing flow in Fig 15 allows for the issue analyzer to determine if the issue is a new issue [para 203, Fig 15, element 1502] and thereafter in step 1518 creates an incident pertaining to the new issue if applicable [para 211]. As such, Examiner maintains that Sachan/Turkkan, specifically Sachan does teach ‘a new enterprise application incident ticket’ as claimed.
Applicant argues that Sachan/Turkkan does not teach the added limitations of ‘displaying corresponding descriptive text hashes for each of the semantically similar documents to a user via a user interface’. However, Examiner respectfully disagrees. Sachan discloses that similar historical incidents and their respective incident descriptions are displayed in section 1000 of the interface in Fig 10 which is used in training or retraining the machine learning based models based on user feedback [para 141, Fig 10]. Sachan also discloses that the similar historical incidents have been feature hashed [para 123, Fig 8, element 812]. As such, Examiner submits that the display of the similar historical incidents are descriptive text hashes because they are feature hashed. Examiner maintains that Sachan/Turkkan, specifically Sachan does teach ‘displaying corresponding descriptive text hashes for each of the semantically similar documents to a user via a user interface’, as claimed.
The 35 USC 103 rejections of all pending claims are maintained for at least the reasons stated above and further in view of the new grounds of rejection.
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 for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3 and 5-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2020/0293946 by Sachan et al (hereafter Sachan), and further in view of US Patent 12,299,397 issued to Turkkan et al (hereafter Turkkan).
Referring to claim 1, Sachan discloses a system associated with incident tickets [para 29, 39-51, incident classification and resolution apparatus 100, Fig 1], comprising:
an incident ticket data store containing electronic records, each record being associated with an enterprise application incident ticket for an application problem and including an incident ticket identifier, incident ticket descriptive text explaining the problem, and supplemental data [incident description, short description and other technical details related to the incident are stored in relational database/incident repository, para 117, 120, Fig 8, element 800] including a ticket priority [incident metadata, para 29; severity level, para 31];
an incident ticket framework, coupled to the incident ticket data store, including: a computer processor, and a computer memory storing instructions that, when executed by the computer processor [Fig 16, processor 1602, memory storing instructions 1604, para 212], cause the incident ticket framework to, for a new enterprise application incident ticket [new incident issue, para 203, Fig 15, element 1502], perform:
retrieving an incident ticket identifier, incident ticket descriptive text and the supplemental data [incident information is pulled from incident repository, wherein the incident information includes description, short description textual data and other technical details related to the incident, para 117-118 and 120, Fig 8, element 802,806],
performing a hash function on the incident ticket descriptive text to create a semantic descriptive text hash based on a semantic hashing technique, wherein the semantic hashing technique is a contextual condensation process [feature hashing is performed on text documents associated with the incident to generate numeric feature vectors and to achieve dimensionality reduction, para 123, Fig 8, element 812],
automatically mapping the semantic descriptive text hash to a cluster of similar incident tickets [para 29; the hashed features are used to build the machine learning based incident nature model 130, para 125; the description of the incident, short description of the incident and category are utilized as input features to predict a sub-category of the incident which is the output feature of the machine learning based incident nature model 130, para 127, Fig 8, element 820; the input parameters of the description of the incident and short description of the incident are used to determine a correct assignment group for each incident ticket, para 208, see Fig 15; incidents are checked to see if they are actionable, para 207, Fig 15, element 1510; if incident ticket is actionable, cosine similarity may be used to measure the similarity of new incident ticket with a set of one or more clusters of historical incidents, para 195, Fig 14, element 1404-1408], and
displaying corresponding descriptive text hashes for each of the semantically similar documents to a user via a user interface [similar historical incidents and their respective incident descriptions are displayed in section 1000 of the interface, para 141, Fig 10; wherein the machine learning model is trained or retrained based on user feedback which includes the displayed similar historical incidents that have been feature hashed, see para 141, Fig 10; para 123, Fig 8, element 812], and in response to receiving a user input to store information for the new enterprise application incident ticket [user notification is received regarding an issue that the user is experiencing, see Fig 15, element 1502], storing the incident ticket identifier and the mapped cluster in a condensed hash database [the assignment groups and routing information are used to create (i.e. store) an incident with the management system, para 208, 211, Fig 15, element 1518].
Referring to claim 1, while Sachan discloses all of the above claimed subject matter and also discloses: using feature hashing on the text documents associated with the incident to generate numeric feature vectors [para 123, Fig 8, element 812], applying statistical tests to the hashed features to measure feature significance, which facilitates ranking the feature vectors based on their predictive power [para 125], and using cosine similarity as a heuristic to measure text similarity (i.e. semantic similarity) between clusters of incident records in response to a new issue/incident ticket received [para 181-182, Fig 13, elements 1300-1304], it remains silent as to:
the supplemental incident ticket data including an enterprise identifier, an application identifier, an incident ticket reporter identifier, an occurrence date, and a ticket status; that the vectors are generated from the supplemental data, creating an address space that includes vectors, positioning a document in the address space, and determining semantically similar documents based on their proximity to a location of the document in the address space.
Turkkan teaches an incident report 600 structure with supplemental fields such as ‘assigned to’ 610 (enterprise identifier), ‘category’ 608 (application identifier), ‘originator’ 602 (incident ticket reporter identifier), ‘created’ date 604 (occurrence date), and ‘status’ 612 (ticket status) [Fig 6, col. 17, line 62 – col. 18, line 28]. Turkkan furthermore discloses determining word and paragraph vectors from samples of text records present in a corpus of text records and determining similarity values between the samples of text and a query text from an incident report using an ANN model that provides compact semantic representations of words and text-strings [col. 22, lines 25-63; database 702 (Fig 7) includes incident reports, col. 18, lines 56-57, col. 23, lines 3-39]. Turkkan also discloses that word vectors of words that have similar meaning or semantic content are placed near each other in a semantically encoded vector space and that the similarity values between the samples of text can be determined using a cosine similarity [col. 23, lines 3-39; Fig 11, elements 1104-1106 and corresponding portions of specification].
Sachan and Turkkan are analogous art because they are directed to the same field of endeavor- classification of incident tickets. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the incident ticket metadata and the feature hashing of the incident tickets to determine semantic similarity between the numerical vectors in Sachan to include the incident report fields and to include the word vectors and determination of their similarity through cosine similarity heuristic of Turkkan because it would achieve predicable results.
The ordinary skilled artisan would have been motivated to make this modification because the incident report fields of Turkkan further refine the types of metadata within the incident ticket of Sachan. Furthermore, the cosine similarity heuristic applied to word vectors of Turkkan, further refines the semantic similarity measures between the numerical vectors for text records in Sachan. This modification would be reasonable since both references have textual content within the incident records that are being vectorized.
Referring to claim 11, Sachan discloses a computer-implemented method associated with incident tickets [para 29, Abstract], comprising:
receiving, by a computer processor of an incident ticket framework [Fig 16, processor 1602, incident classification and resolution apparatus 100, Fig 1] from an incident ticket reporter [issue analyzer 102, para 52, Fig 1], a new incident ticket associated with an application problem including new incident ticket descriptive text explaining the problem and supplemental data [incident description, short description and other technical details related to the incident are stored in relational database/incident repository, para 117, 120, Fig 8, element 800; incident information including description and short description textual data is retrieved, para 117-118 and 120, Fig 8, element 802,806; new incident issue, para 203, Fig 15, element 1502] including a ticket priority [incident metadata, para 29; severity level, para 31];
performing a hash function on the new incident ticket descriptive text to create a semantic descriptive text hash based on a semantic hashing technique wherein the semantic hashing technique is a contextual condensation process [feature hashing is performed on text documents associated with the incident to generate numeric feature vectors and to achieve dimensionality reduction, para 123, Fig 8, element 812];
automatically determining semantically similar incident tickets based on clusters in a condensed hash database [para 29; the hashed features are used to build the machine learning based incident nature model 130, para 125; the description of the incident, short description of the incident and category are utilized as input features to predict a sub-category of the incident which is the output feature of the machine learning based incident nature model 130, para 127, Fig 8, element 820; the input parameters of the description of the incident and short description of the incident are used to determine a correct assignment group for each incident ticket, para 208, see Fig 15; incidents are checked to see if they are actionable, para 207, Fig 15, element 1510; if incident ticket is actionable, cosine similarity may be used to measure the similarity of new incident ticket with a set of one or more clusters of historical incidents, para 195, Fig 14, element 1404-1408]; and
displaying corresponding descriptive text hashes for each of the semantically similar documents to a user via a user interface [similar historical incidents and their respective incident descriptions are displayed in section 1000 of the interface, para 141, Fig 10; wherein the machine learning model is trained or retrained based on user feedback which includes the displayed similar historical incidents that have been feature hashed, see para 141, Fig 10; para 123, Fig 8, element 812], and in response to receiving a user input to store information for the new enterprise application incident ticket [user notification is received regarding an issue that the user is experiencing, see Fig 15, element 1502], storing the incident ticket identifier and a mapped cluster in a condensed hash database [the assignment groups and routing information are used to create (i.e. store) an incident with the management system, para 208, 211, Fig 15, element 1518].
Referring to claim 11, while Sachan discloses all of the above claimed subject matter and also discloses: using feature hashing on the text documents associated with the incident to generate numeric feature vectors [para 123, Fig 8, element 812], applying statistical tests to the hashed features to measure feature significance, which facilitates ranking the feature vectors based on their predictive power [para 125], and using cosine similarity as a heuristic to measure text similarity (i.e. semantic similarity) between clusters of incident records in response to a new issue/incident ticket received [para 181-182, Fig 13, elements 1300-1304], it remains silent as to:
the supplemental incident ticket data including an enterprise identifier, an application identifier, an incident ticket reporter identifier, an occurrence date, and a ticket status; that the vectors are generated from the supplemental data, creating an address space that includes vectors, positioning a document in the address space, and determining semantically similar documents based on their proximity to a location of the document in the address space.
Turkkan teaches an incident report 600 structure with supplemental fields such as ‘assigned to’ 610 (enterprise identifier), ‘category’ 608 (application identifier), ‘originator’ 602 (incident ticket reporter identifier), ‘created’ date 604 (occurrence date), and ‘status’ 612 (ticket status) [Fig 6, col. 17, line 62 – col. 18, line 28]. Turkkan furthermore discloses determining word and paragraph vectors from samples of text records present in a corpus of text records and determining similarity values between the samples of text and a query text from an incident report using an ANN model that provides compact semantic representations of words and text-strings [col. 22, lines 25-63; database 702 (Fig 7) includes incident reports, col. 18, lines 56-57, col. 23, lines 3-39]. Turkkan also discloses that word vectors of words that have similar meaning or semantic content are placed near each other in a semantically encoded vector space and that the similarity values between the samples of text can be determined using a cosine similarity [col. 23, lines 3-39; Fig 11, elements 1104-1106 and corresponding portions of specification].
Sachan and Turkkan are analogous art because they are directed to the same field of endeavor- classification of incident tickets. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the incident ticket metadata and the feature hashing of the incident tickets to determine semantic similarity between the numerical vectors in Sachan to include the incident report fields and to include the word vectors and determination of their similarity through cosine similarity heuristic of Turkkan because it would achieve predicable results.
The ordinary skilled artisan would have been motivated to make this modification because the incident report fields of Turkkan further refine the types of metadata within the incident ticket of Sachan. Furthermore, the cosine similarity heuristic applied to word vectors of Turkkan, further refines the semantic similarity measures between the numerical vectors for text records in Sachan. This modification would be reasonable since both references have textual content within the incident records that are being vectorized.
Referring to claim 18 the limitations of the claim are similar to those of claim 11 in the form of computer readable media storing instructions [Sachan, para 29]. As such, claim 18 is rejected for the same reasons as claim 11.
Referring to claims 3, 12 and 19, Sachan/Turkkan discloses that the contextual condensation process includes a Machine Learning (“ML”) Natural Language Processing (“NLP”) algorithm [Sachan, Feature hashing is performed on text documents associated with the incident to generate numeric feature vectors, para 123, Fig 8, element 812].
Referring to claim 5, Sachan/Turkkan discloses that semantically similar documents are assigned to a cluster of similar incident tickets and stored in the condensed hash database along with the incident ticket identifier [Sachan, the assignment groups and routing information are used to create an incident with the management system, list of assignment groups, para 208, 211, Fig 15, element 1518].
Referring to claim 6, Sachan/Turkkan discloses that supplemental information about documents is included in the semantic hashing function [Sachan, text for the incident includes description and short description, para 120; feature hashing of text associated with incident, para 123].
Referring to claim 7, Sachan/Turkkan discloses that the supplemental information comprises: an enterprise identifier, an application identifier, an incident ticket reporter identifier, an occurrence date, a ticket priority, and a ticket status [Sachan, incident includes description and short description text, para 120, 123].
Referring to claim 8, Sachan/Turkkan discloses that the incident ticket framework is further to receive, from an incident ticket reporter, a new incident ticket and determine semantically similar incident tickets based on the clusters in the condensed hash database [Sachan, para 29; Turkkan, col. 25, lines 50-63].
Referring to claims 9 and 16, Sachan/Turkkan discloses that the incident ticket framework is further to provide, to an incident ticket responder, information about the new incident ticket and the semantically similar incident tickets [Sachan, para 53-57, Fig 2].
Referring to claims 10 and 17, Sachan/Turkkan discloses that the incident ticket framework is further to automatically generate an alert message and transmit the alert message to at least one of: (i) the incident ticket reporter, and (ii) the incident ticket responder [Sachan, dashboard, see Fig 10, 11 and corresponding portions of specification].
Referring to claim 13, Sachan/Turkkan discloses providing information about the semantically similar incident tickets to the incident ticket reporter via a Graphical User Interface (‘GUI’) [Sachan, see similar historical incidents 1000, Fig 10 and corresponding portions of specification].
Referring to claim 14, Sachan/Turkkan discloses that the information about the semantically similar incident tickets include links to those incident tickets in an incident ticket data store [Sachan, Fig 6, element 606, incident recommendation includes hyperlink for an incident number, para 99].
Referring to claim 15, Sachan/Turkkan discloses that the information about semantically similar incident tickets is at least one of: (i) searchable by the incident ticket reporter, and (ii) sortable by the incident ticket reporter [Sachan, hyperlink is searchable, para 99; incident resolution recommendation includes relevant historical incidents determined, para 104].
Claim 20 is a combination of claims 13, 16 and 17 and is rejected for the same reasons as the latter claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Tian (US 2020/0073959) directed to: generating respect sets of feature hashes for respective features of a file; performing feature hashing to obtain fuzzy hash values to determine which cluster data belongs to [Abstract; para 16; entire document];
De et al (US 2024/0211682): directed to extracting features from writing data into hash values and generating and displaying summaries for the writing data and refining the baseline machine learning model based on the hash values and selected summary to generate a personalized machine learning model [Abstract; Fig 4-6 and corresponding portions of specification].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHERYL M SHECHTMAN whose telephone number is (571)272-4018. The examiner can normally be reached on M-F: 10am-6:30pm.
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, Amy Ng can be reached on 571-270-1698. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
CHERYL M SHECHTMANPatent Examiner
Art Unit 2164
/C.M.S//AMY NG/Supervisory Patent Examiner, Art Unit 2164
Prosecution Insights