DETAILED ACTION
This communication is responsive to the application, filed January 13, 2026. Claims 1-18, 21, and 22 are pending in this application. The applicant has canceled claim 19. The applicant has added new claim 22.
Examined under the first inventor to file provisions of the AIA
The present application was filed on January 19, 2024, which is on or after March 16, 2013, and thus is being examined under the first inventor to file provisions of the AIA .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1, 2, 6-9, 13-16, and 20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1, 2, 4, 6-9, 11, 13-16, 18, and 20 of copending Application No. 18/417,501 (reference application) in view of Lo et al. (US 12,061,970 B1). Although the claims at issue are not identical, they are not patentably distinct from each other because the claims of present application are obvious variants of the claims of copending Application No. ‘501.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Claims 1, 2, 6-9, 13-16, and 20 are compared to claims 1, 2, 4, 6-9, 11, 13-16, 18, and 20 of US Application No. 18/417,501 in the following table:
Instant Application
US Application : 18/417,501
1. A method for managing data processing systems based on indications of a failure, comprising:
obtaining a data request, from a requestor, for data stored in a structured knowledge repository, the data comprising structured knowledge attributes extracted from an internal architecture of a trained machine learning model, the internal architecture controls how the trained machine learning model generates inferences and the internal architecture is inaccessible to the requestor, and the user preference data comprises at least one of a user communication history, a user style of communication format, or user feedback of the requestor;
obtaining user preference data from a local domain context repository, wherein the user preference data is associated with the requestor, and the local domain context repository is separate and distinct from the structured knowledge repository;
obtaining one or more responses to the data request using, at least, the structured knowledge repository and the user preference data; and
providing at least one of the one or more responses to the requestor, through an interactive user interface through which the data request was received, to service the data request, wherein each of the one or more responses comprises a failure prediction and a portion of the structured knowledge attributes that provide visibility for the requestor into understanding how and why the trained machine learning model generated the failure prediction in a manner that the trained machine learning model generated the failure prediction, the failure prediction being one of the inferences.
1. A method for managing data processing systems based on indications of a failure, comprising:
obtaining a data request, from a requestor, for data stored in a structured knowledge repository, the data comprising structured knowledge attributes extracted from an internal architecture of a trained machine learning model, the internal architecture controls how the trained machine learning model generates inferences and the internal architecture is inaccessible to the requestor, but fail to explicitly disclose user preference data comprising user style of communication. Lo discloses a similar method, which further teaches [col. 1, lines 29-45] a user profile associated with a user, wherein the user profile includes user persona attributes and user parameters and generating response based on the user profile. It would have been obvious to modify ‘501 with Lo because it allows to respond based on user profile;
4. obtaining system capability data from system capability repository, the system capability repository being separate and distinct from the structured knowledge repository;
(It is clear that the user data of the instant application and the system capability data of application ‘501 can be similar types of data as shown in the specification of application ’501 at paragraphs [0195-0198]).
obtaining one or more responses to the data request using the structured knowledge repository;
providing at least one of the one or more responses to the requestor, through an interactive user interface through which the data was received, to service the data request, wherein each of the one or more responses comprises a failure prediction and a portion of the structured knowledge attributes that provide visibility for the requestor into understanding how and why the trained machine learning model generated the failure prediction in a manner that the trained machine learning model generated the failure prediction, the failure prediction being one of the inferences.
2. The method of claim 1, wherein the structured knowledge attributes usable to manage an indication of the failure for a data processing system of the data processing systems.
2. The method of claim 1, wherein the structured knowledge attributes usable to manage an indication of the failure for a data processing system of the data processing systems.
6. The method of claim 2, further comprising: prior to generating the one or more responses: identifying an occurrence of the failure, the failure being of the data processing system; and based on the occurrence, using an inference model to obtain an indication of a root cause for the failure, the structured knowledge repository being based, at least in part, on the inference model and logs on which the inference model is based, the inference model being the trained machine learning model that generates the failure prediction, the failure prediction being generated in further view of the indication of failure, and the indication of the root cause being specified in the failure prediction.
6. The method of claim 2, further comprising: prior to generating the one or more responses: identifying an occurrence of the failure, the failure being of the data processing system; and based on the occurrence, using an inference model to obtain an indication of a root cause for the failure, the structured knowledge repository being based, at least in part, on the inference model and logs on which the inference model is based, the inference model being the trained machine learning model that generates the failure prediction, the failure prediction being generated in further view of the indication of failure, and the indication of the root cause being specified in the failure prediction.
7. The method of claim 6, further comprising: after providing the at least one of the one or more responses: assessing a likelihood of the root cause being accurate using the failure prediction response; and in an instance of the assessing where the likelihood meets a threshold: identifying at least one remediation action based on the root cause; and performing the at least one remediation action to obtain an updated data processing system to attempt to remediate the failure.
7. The method of claim 6, further comprising: after providing the at least one of the one or more filtered responses: assessing a likelihood of the root cause being accurate using the failure prediction response; and in an instance of the assessing where the likelihood meets a threshold: identifying at least one remediation action based on the root cause; and performing the at least one remediation action to obtain an updated data processing system to attempt to remediate the failure.
Claims 8, 9, 13, and 14 recite a machine-readable medium claims and contain similar subject matter as the method claims 1, 2, 6, and 7 above. Claims 8, 9, 13, and 14 of the instant application and claims 8, 9, 13, and 14 of copending application ‘501 contain the same subject matter and are provisionally rejected on the ground of nonstatutory obviousness type double patenting for the same reasons as method claims 1, 2, 6, 7 described in the table above.
Claims 15 and 16 recite a system claims and contain similar subject matter as the method claims 1, 2, 6, and 7 above. Claims 15 and 16 of the instant application and claims 15 and 16 of copending application ‘501 contain the same subject matter and are provisionally rejected on the ground of nonstatutory obviousness type double patenting for the same reasons as method claims 1, 2, 6, 7 described in the table above.
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 of this title, 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.
Claims 1-6, 8-13, 15-18, 21 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. (US 2024/0168835 A1) in view of Lo et al. (US 12,061,970 B1) and further in view of Li et al. (US 2019/0244122 A1).
As per claim 1: A method for managing failures of data processing systems, comprising and by a data processing system manager configured to manage the data processing systems:
obtaining a data request, from a requestor, for data stored in a structured knowledge repository,
obtaining one or more responses to the data request using, at least, the structured knowledge repository and the user preference data; and
providing at least one of the one or more responses to the requestor, through an interactive user interface through which the data request was received, to service the data request,
and the user preference data comprises at least one of a user communication history, a user style of communication format, or user feedback of the requestor;
Wang discloses [0008-0014] optimizing a decision tree-based hard disk failure prediction model by using the hard disk failure prediction key database to obtain a model and acquiring SMART attribute values to predict if target hard disk is normal, in poor condition, or the disk is about to fail. Wang discloses obtaining data stored in knowledge repository and obtain data request using knowledge repository and user preference [Wang; 0063], but fails to explicitly disclose servicing the data request based on user data and knowledge repository. Lo discloses a similar method, which further teaches [col. 1, lines 29-45] a user profile associated with a user, wherein the user profile includes user persona attributes and user parameters and generating response based on the user profile. Lo further discloses [col. 11, lines 24-45] based on the user and the conversation, the model may load the data sources and/or agents needed to fulfill the response. Lo further discloses [col. 10, lines 57-67] the context engine may review the conversation occurring via the GUI and determine how much conversation history is required to maintain the conversation. The context engine performs this dynamically and with the injection of context data to enable seamless conversation and user feedback in response to previous messages.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Wang with that of Lo. One would have been motivated to service data request based on user and knowledge repository because it allows to load the data sources and/or agents needed to fulfill the response [Lo; col. 11, lines 24-45].
the data comprising structured knowledge attributes extracted from an internal architecture of a trained machine learning model, the internal architecture controls how the trained machine learning model generates inferences and the internal architecture is inaccessible to the requestor; obtaining user preference data from a local domain context repository, wherein the user preference data is associated with the requestor, the local domain context repository is separate and distinct from the structured knowledge repository,
wherein each of the one or more responses comprises a failure prediction and a portion of the structured knowledge attributes, the portion providing visibility for the requestor into understanding how and why the trained machine learning model generated the failure prediction in a manner that the trained machine learning model generated the failure prediction, and the failure prediction being one of the inferences.
Wang and Lo disclose knowledge attributes and knowledge repository, but fail to explicitly disclose internal architecture generates inferences and provide visibility to a failure prediction. Li discloses a similar method, which further teaches [Fig. 2; 0019, 0037-0053] an explainable AI system that generates knowledge models comprising ontologies and inferencing rules for generating explanations for decisions made by the AI system. A knowledge model constructor that creates ontologies from data and constructs inferencing rules that form the basis of the knowledge model used for explainable AI, the basis of the explanation that the system provides to the user for a decision. The system extracts relations and inferencing rules from curated data, which represent internal reasoning structures of the AI model and an explainer component that processes the deconstructed problem and uses the internal reasoning structures derived from the trained model’s architecture to provide explanations. Li further discloses [Fig. 10; 0138-0143] the system stores the extracted inferencing rules and relations (representing the internal architecture) and uses them to generate machine reasoning and explanations that accompany the hypothesis/decision.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teachings of Wang and Lo with that of Li. One would have been motivated to have internal architecture control how learning model generates inferences because doing so enables the system to provide explainable AI allowing users to understand the reasoning process [Li; 0140-0142].
As per claim 2: The method of claim 1, wherein the structured knowledge attributes are usable to manage an indication of failure for a data processing system of the data processing systems.
Wang discloses [0008-0014] optimizing a decision tree-based hard disk failure prediction model by using the hard disk failure prediction key database to obtain a model and acquiring SMART attribute values to predict if target hard disk is normal, in poor condition, or the disk is about to fail.
As per claim 3: The method of claim 2, further comprising by the data processing system manager:
filtering the structured knowledge attributes using the user preference data to obtain filtered structured knowledge attributes; and
Wang discloses [0050-0051] SMART attribute values are filtered by using a Relief algorithm to obtain the filtered SMART attribute values to improve the hard disk failure prediction model for prediction.
generating a customized user response prompt using the user preference data, the filtered structured knowledge attributes, and one or more generic response prompts, wherein the one or more responses to the data request is generated using the customized user response prompt.
Lo discloses [col. 1, lines 29-45] a user profile associated with a user, wherein the user profile includes user persona attributes and user parameters and generating response based on the user profile. Lo further discloses [col. 11, lines 24-45] based on the user and the conversation, the model may load the data sources and/or agents needed to fulfill the response.
As per claim 4: The method of claim 3, wherein the local domain context repository is implemented as cache memory.
Lo discloses [col. 10, lines 57-67] the context engine may review the conversation occurring via the GUI and determine how much conversation history is required to maintain the conversation. The context engine performs this dynamically and with the injection of context data to enable seamless conversation and user feedback in response to previous messages.
As per claim 5: The method of claim 4, further comprising by the data processing system manager: converging the one or more responses using the structured knowledge repository and the user preference data to obtain a converged response, wherein the at least one of the one or more responses that is provided to the requestor is the converged response.
Lo discloses [col. 11, lines 1-23] converging one or more responses using the knowledge and previous user data messages to generate a converged response, which is provided to the user.
As per claim 6: The method of claim 2, further comprising by the data processing system manager:
prior to generating the one or more responses: identifying an occurrence of the failure, the failure being of the data processing system; and based on the occurrence, using an inference model to obtain an indication of a root cause for the failure, the structured knowledge repository being based, at least in part, on the inference model and logs on which the inference model is based, the inference model being the trained machine learning model that generates the failure prediction, the failure prediction being generated in further view of the indication of failure, and the indication of the root cause being specified in the failure prediction.
Wang discloses [0008-0014] optimizing a decision tree-based hard disk failure prediction model by using the hard disk failure prediction key database to obtain a model and acquiring SMART attribute values to predict if target hard disk is normal, in poor condition, or the disk is about to fail.
As per claims 8-13: Although claims 8-13 are directed towards a medium claim, they are rejected under the same rationale as the method claims 1-6 above.
As per claims 15-18: Although claims 15-18 are directed towards a system claim, they are rejected under the same rationale as the method claims 1-6 above.
As per claim 21: The method of claim 1, further comprising and by the data processing system manager prior to obtaining the data request: extracting the structured knowledge attributes from the internal architecture of the trained machine learning model, the trained machine learning model being hosted by the data processing system manager; and storing the structured knowledge attributes extracted from the internal architecture of the trained machine learning model into the structured knowledge repository.
Li discloses a similar method, which further teaches [Fig. 2; 0019, 0037-0053] an explainable AI system that generates knowledge models comprising ontologies and inferencing rules for generating explanations for decisions made by the AI system. A knowledge model constructor that creates ontologies from data and constructs inferencing rules that form the basis of the knowledge model used for explainable AI, the basis of the explanation that the system provides to the user for a decision. The system extracts relations and inferencing rules from curated data, which represent internal reasoning structures of the AI model and an explainer component that processes the deconstructed problem and uses the internal reasoning structures derived from the trained model’s architecture to provide explanations. Li further discloses [Fig. 10; 0138-0143] the system stores the extracted inferencing rules and relations (representing the internal architecture) and uses them to generate machine reasoning and explanations that accompany the hypothesis/decision.
As per claim 22: The method of claim 1, wherein the structure knowledge attributes are extracted from the internal architecture of the trained machine learning model using explainable AI techniques.
Li is explicitly [Abstract; 0005-0021] an explainable AI system. It constructs data-driven ontologies and inferencing rules, representing the internal reasoning structures of the AI system, from real-world data, and uses these as the basis for explanations. The knowledge model (ontologies/rules) and provenance of reasoning graphs function as structured knowledge extracted from the internal reasoning framework of the AI system.
Allowable Subject Matter
Claims 7 and 14 are objected to as being dependent upon a rejected base claim, but would be allowable if they overcome the Double Patenting rejection above and are rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-18, 21, and 22 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
The following prior art made of record and not relied upon is cited to establish the level of skill in the applicant’s art and those arts considered reasonably pertinent to applicant’s disclosure. See MPEP 707.05(c).
· US 2022/0171991 A1 – Das discloses capturing feature attribution and bias metrics from models in an ML pipeline and generating views for them and presenting such metrics as visual views, which include feature-importance plots and attribution information that explain model predictions.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIGAR P PATEL whose telephone number is (571)270-5067. The examiner can normally be reached on Monday to Friday 10AM-6PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ashish Thomas, can be reached on 571-272-0631. 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 https://ppair-my.uspto.gov/pair/PrivatePair. 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.
/JIGAR P PATEL/Primary Examiner, Art Unit 2114
Prosecution Insights