DETAILED ACTION
This communication is responsive to the application, filed March 17, 2026. Claims 1-20 are pending in this application.
Examined under the first inventor to file provisions of the AIA
The present application was filed on May 31, 2024, which is on or after March 16, 2013, and thus is being examined under the first inventor to file provisions of the AIA .
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over Tanner et al. (US 2009/0326784 A1) in view of Sinclair et al. (US 7,668,953 B1) and further in view of Bartz et al. (US 8,453,027 B2).
As per claim 1: A method comprising:
receiving, at a remote server, an identifier from a computing system, wherein the identifier identifies a computing system problem that has occurred at the computing system;
identifying, at the remote server based on the identified related and similar errors, second problem analysis data relating to the computing system problem;
determining, at the remote server, that first problem analysis data, relating to the computing system problem and accessible at the computing system, is out of date compared with the second problem analysis data at the remote server; and
transmitting the second problem analysis data from the remote server to the computing system,
wherein the computing system is configured to receive the second problem analysis data and update a local repository of problem analysis rules and knowledge data, and automatically analyze the second problem analysis data to resolve the computing system problem.
Tanner discloses [Fig. 1; 0020, 0049, 0106-0110] identifying a computing system problem based on identifier features generated at the computing system and calculating cores to identify probable fail cases of the system. Tanner further teaches associating fail cases with weighting factors to identify probably failed components, and storing the rules and weighting factors in updatable look-up table that may be altered during the life of the system. Tanner discloses identifying computing system problem, but fails to explicitly disclose remote server that stores global problem-analysis rules and knowledge data and transmitting updated problem analysis data. Sinclair discloses a similar method, which further teaches [Figs. 3 and 5; col. 3 and cols. 8-10] an RBML broker and RBML repository that centrally store rules, a call home application that receives events, local rule cache that stores rules obtained from the broker, and diagnosis engine that uses those rules to verify problems and perform corrective action.
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 Tanner with that of Sinclair. One would have been motivated to combine Sinclair with Tanner in order to centrally manage Tanner’s rule-based fail-case diagnostic knowledge, distribute updated rules to the managed system, and automate problem diagnosis and correction in a call-home environment [Sinclair; col. 8-10].
evaluating the computing system problem, based on the identifier and global problem analysis rule and knowledge data of a remote server database at the remote server, to identify related and similar errors;
Tanner and Sinclair disclose distributing updated rules and automating problem diagnosis and correction, but fail to explicitly disclose identifying related and similar errors by comparing the current problem with a historical problem and update the problem-analysis data. Bartz discloses a similar method, which further teaches [col. 3, lines 11-50; col. 6, lines 43-63] receipt of a new error report, comparison against previously received error reports, computation of a similarity value, determination whether the similarity is above a threshold, and identification of reports as similar and/or caused by the same error.
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 Tanner and Sinclair with that of Bartz. One would have been motivated to combine Bartz with Tanner and Sinclair to identify related and similar errors at the remote server and update the second problem-analysis data based on the similarity determination [Bartz; col. 6, lines 51-63].
As per claim 2: The method of claim 1, wherein the second problem analysis data comprises one or more problem analysis rules used to resolve the computing system problem, and wherein the one or more problem analysis rules are used by the computing system to identify the solution to the computing system problem.
Sinclair discloses [col. 3, lines 17-67] the second problem analysis data as rules/knowledge used by the computing system to identify a solution, including problem rules stored in rule repository, distributed to rule cache, and used by correlation/diagnosis engine to diagnose problems and apply corrective action.
As per claim 3: The method of claim 2, wherein the one or more problem analysis rules comprise at least one of: (i) an error priority rule, (ii) a call-home rule relating to transmission between the computing system and a remote system, (iii) a time thresholding rule relating to a duration to ignore duplicate problem identifiers, or (iv) a count threshold rule relating to a number of times an error occurs before undertaking a transmission from the computing system to the remote system.
Tanner discloses [0175-0177] the weighting factors may be determined based on the results. The weighting factors may also be altered during the life of the components. The weighting factors are held with the rules in the updatable look-up table and therefore be altered if new knowledge is gained.
As per claim 4: The method of claim 3, wherein the one or more problem analysis rules comprise the error priority rule.
Tanner discloses [0175-0177] the weighting factors may be determined based on the results. The weighting factors may also be altered during the life of the components.
As per claim 5: The method of claim 3, wherein the one or more problem analysis rules comprise the call-home rule.
Sinclair discloses [col. 8, lines 39-56] a call home arrangement in which a device communicates a fault/event to appliance and call home application through the network, with rules in the RBML broker/repository controlling diagnosis and communication to the managed device.
As per claim 6: The method of claim 3, wherein the one or more problem analysis rules comprise the time thresholding rule.
Tanner discloses [0008] recognizing a fail case when enough fault tokens are generated within a certain time limit threshold.
As per claim 7: The method of claim 3, wherein the one or more problem analysis rules comprise the count threshold rule.
Tanner discloses [0136] after the fail cases have been scored, they may be post-processed to remove all but those with the highest scores. The threshold can be taken to be a defined percentage of the maximum score.
As per claim 8: The method of claim 1, wherein the second problem analysis data comprises problem analysis knowledge, and wherein the problem analysis knowledge is used by the computing system to identify the solution to the computing system problem.
Sinclair discloses [col. 3, lines 17-67] the second problem analysis data comprising problem analysis knowledge used to identify a solution, including problem documents, diagnosis documents, symptoms documents, and rules in rule cache that are used by the correlation/diagnosis engines to determine problems and apply corrective action.
As per claim 9: The method of claim 8, wherein the problem analysis knowledge relates to at least one of: (i) duplicate error knowledge, (ii) hardware update knowledge, (iii) code patch level where a problem was fixed knowledge, (iv) field replaceable unit (FRU) knowledge, or (v) whitelisted error knowledge.
Sinclair discloses [Figs. 3 and 5; col. 3, lines 17-67; cols. 8-10] rules/knowledge for problem diagnosis, symptom correlation, inventory, and corrective action, which correspond to the claimed duplicate error, hardware/update, patch-level, FRU, and whitelisted-error knowledge categories as diagnostic knowledge maintained in the RBML repository and rule cache.
As per claim 10: The method of claim 1, wherein the identifying the computing system problem based on the identifier generated at the computing system, comprises: determining that the problem is the same error as a second, historical problem, based on comparing a similarity between the problem and the second historical problem using a cross-error threshold.
Tanner discloses [0153-0154] multiple fail cases may be detected as possible matches to a received pattern that has equal or similar scores (threshold). This allows to identify the probable failed component.
As per claims 11-15: Although claims 11-15 are directed towards a medium claim, they are rejected under the same rationale as the method claims 1-10 above.
As per claims 16-20: Although claims 16-20 are directed towards a system claim, they are rejected under the same rationale as the method claims 1-10 above.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 11, and 16 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 2008/0209274 A1 – Nicholson discloses the server analyses the data in order to determine trends in failure performance of the population of devices in order to improve designs and provide updated software for distribution to the devices via the internet.
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