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 .
Claims 1-19 are pending for examination.
This Office Action is Non-Final.
The RCE filed 07/08/2026 has been entered.
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 (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.
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.
Claims 1-7, 9-16, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Kairali et al. (US 11561849 B1, as previously cited, hereinafter “Kairali”) in view of StackOverflow (NPL: “Occasionally getting Youtube iframe player error message…”).
Regarding Claim 1, Kairali discloses a method (Fig. 6A-6B) comprising:
continuously examining, via a defect log analyzer, incoming logs to detect anomalies and failures based on predefined and dynamically learned markers (Fig. 6A, steps 601-610; Col 25, lines 53-67; Col 26, lines 1-22: service mesh 211 collects and stores the history of the API call being made to predict the error rate of the API call (“detect anomalies and failures”) via knowledge base 208 of the first AI module 202. Col 19, lines 6-22: rules of knowledge base 208 may be fixed to cover all or nearly all situations by the knowledge base 208 in if-then statement format, where rules are processed by the reasoning engine of knowledge base 208 to provide machine-based line of reasoning. Col 20, lines 6-21: first AI module 202 and knowledge base 2078 uses various training methods (supervised learning, unsupervised learning, and/or semi-supervised learning) to draw conclusions about error rates, hence examines logs and predicts error rates based on “dynamically learned markers” from the training methods. In other words, knowledge base 208 of first AI module 202 (“defect log analyzer”) continuously examines incoming API historical logs to predict/detect error rates based on predefined if-then format rules and dynamically learned markers from training methods);
detecting, via the defect log analyzer, critical log errors in the examined incoming logs that affect system performance (Fig. 6A, step 605-607 and Col 26, lines 8-11: knowledge base 208 checks and analyzes current error rates and historical error rates for microservice chain being invoked in API call. Col 17, lines 59-63: the examined current and historical error rates are incoming stored logs from DB 219 (Col 16, lines 20-35: historical DB 219) and health module 206 (Col 17, lines 19-44), wherein the detected error rates indicate failed API system performance);
categorizing failures associated with the detected critical log errors, via a defect use case identifier, by revealing underlying patterns associated with the detected critical log errors (Fig. 6A, step 609-610 and Col 26, lines 11-22: knowledge base 208 (also a “defect use case identifier”) analyzes current and historical error rates and predicts the error rate of the API call for the user profile invoking the API call. Col 19, lines 28-34: predicting involves categorizing a failing probability associated with the detected historical log errors by revealing underling failure patterns associated with the detected historical log errors (e.g., high likelihood of error if user 1 invokes microservice chain M1-M2-M3-M4 if microservice M4 is observed to be failing 90% of the time over last 24 hours when user 1 makes the API call));
identifying, via the defect use case identifier, use cases related to the categorized failures using root cause analysis of the underlying patterns, wherein the use cases are associated with user sets (Col 19, lines 25-42: knowledge base 208 identifies the microservice chain regularly invoked by an API call (“use case”) when categorizing/predicting error rates of the microservice chain using RCA of underlying patterns (e.g., microservice M4 observed to be failing 90% of the time; M4 identified as a root case for failed API call M1-M2-M3-M4 and contains failing pattern of 90% over last 24 hours when invoked by user 1));
identifying, via a defect similar user set system, specific user sets with a high probability of encountering other use cases that correlate with the identified use cases (Col 19, lines 25-42: knowledge base 208 (also a “defect similar user set system”) predicts/identifies that the API call invoking M1-M2-M3-M4 (“identified use case”) will most likely fail for any existing users (e.g., user 1) and new users trying to invoke the same API call (“other (future) use cases));
dynamically adjusting, via a defect log level controller, log levels for the specific user sets with the high probability of encountering the other use cases, based on the detected critical log errors and the categorized failures (Fig. 6A, steps {610-11, 613, 617-619, 623-627, 631} and Col 27, lines 41-49: based on/after detecting critical historical log errors and categorized API failure rates in step 610, dynamic log level changer 212 of the second AI module 204 (“defect log level controller”) modifies the log levels of proxies 217 to increase the amount of information captured in the logs of application 203 invoking the service chain(s) in step 631 if current log levels are insufficient for the predicted error rate of the API call. Col 15, lines 34-40: proxies 217 direct requests to proper [individual microservice] 215, thus dynamically modifying log levels of proxies 217 also modifies log levels for users requesting the microservice chain (“other use cases”), wherein the requests are routed by proxies 217, based on the previously detected historical log errors and predicted failure rates));
in response to identified failure use cases, initiating a learning phase during which a trained understanding of user-attempted… failure is refined by a logging system using a feedback loop that monitors system performance (Fig. 6A, steps 610-612 and Col 26, lines 28-48: in response to the predicted error rates (i.e., identified predicted failure of invoking/using the microservice chain) and if the error rate prediction made by first AI module 202 is not above a confidence threshold value, dynamic log level changer 212 modifies the log level applied to the proxies 217 to capture more log information collected by services 215 and/or proxies 217 of applications 203 to improve overall confidence of predictions made by the first AI module 202 by increasing the amount of information stored by service mesh metrics DB 219. As described above and in Col 16, lines 7-53, log information collected by proxies 217 and stored in DB 219 encompasses user-attempted failure as user requests are routed to corresponding services 215 by proxies 217 and information about the microservices invoked by the user are logged. Said information includes historical error rates, failures of API calls, users associated with errors and failures, etc. Fig. 6B, steps {633, 635 638, 639, 623} and Col 28 lines 24-29: learning phase interpreted as comprising a feedback loop from step 638 [Wingdings font/0xE0] 623 to check and report current log levels and determine whether current log levels are sufficient for the error rate (step 627-631; see above) for further adjustment (learn whether current log levels are sufficient and adjust via trial-and-error through determination and retry steps 627, 639));
dynamically adjusting, via a defect learning period manager, a duration of the learning phase based on a rate of change in user-attempted… failure (Fig. 6B, step 637 and Col 27, lines 59-65: over time, where the same API call is successful above a threshold amount of time as configured by the service mesh 211, the dynamic log level changer 212 may further adjust the log levels of proxies 217 by lowering log levels. Thus, a learning period duration (threshold time) was effectively previously set/adjusted by service mesh 211 in order to detect (“based on”) a rate of change from failed API call to successful API call (API call failure == “user attempted failure” as user invokes API call – see previous limitations)); and
in response to accumulating a predetermined volume of user logs across log levels and completing the learning phase, dynamically adjusting log levels to refine system configuration, minimize resource usage by targeting the specific user sets for more detailed logging and analysis, and retain critical log information for effective debugging and system monitoring (Fig. 6B, step {627, 629, 633, 635, 637} and Col 27, lines 30-40: in step 629, dynamic log levels are determined sufficient for predicted error rate. Col 27, lines 54-66: if the API call is successful above a threshold amount of time, the dynamic log level changer 212 may adjust log levels of proxies 217 by lowering log levels. Additionally, the successful completion is logged to the service mesh metrics DB 219 and inputted into records of knowledge base 208. Col 24, lines 9-16: log levels were previously increased from INFO to DEBUG in view of predicted failure rates. Lowering said levels after a threshold period of time may involve reverting the log level from DEBUG back to INFO, providing a different (more) detailed logging and analysis in INFO mode. Therefore, in response to meeting sufficient log levels for the error rate (wherein “sufficient log levels” encompass accumulating a predetermined volume of user logs as the amount of information does not need to be increased (see Col 27, lines 41-49) and the determination step encompasses “completing the learning/log level adjustment phase”), log levels are dynamically reduced upon a successful API call. The reduced log levels are adjusted of proxies 217 for more detailed logging and analysis of INFO instead of DEBUG, and the API success (“critical log info”) is logged to service mesh DB 219 and knowledge base 208 for future API failure rate prediction (see Col 16, lines 36-53: historical database – “debugging” (failure prediction/identification) and “system monitoring” (logging system API failures))).
Kairali does not disclose:
…user-attempted playback failure…
However, StackOverflow teaches:
…user-attempted playback failure (Pages 1-2, initial question and 9/11/2020 comment: user executes YouTube iFrame API from the same IP/PC and encounters a playback error)…
Therefore, it would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to which said subject matter pertains to perform a simple substitution of one known element (Kairali: Col 16, lines 7-53; Col 19, lines 25-42: generic user executed API call, resulting in API call failure) for another (StackOverflow: Pages 1-2: user executes YouTube iFrame API call on same IP/PC, resulting in playback error) to obtain predictable results (user-initiated API failure).
Regarding Claim 2, Kairali in view of StackOverflow teaches the method of claim 1, as referenced above, wherein the defect log analyzer logs critical events that capture insights and stores the critical events in a database (Kairali: Col 17, lines 59-67: knowledge base 208 may be structured as a database and may be used to make predictions about API call failure fates using data extracted from service mesh metrics DB 219 (including application logs) and health status mappings provided by health module 206. Col 18, lines 21-30: knowledge base 208 receives and stores data extracted from DB 219 and health module 206. Col 16, lines 24-35 and Col 17, lines 19-44: data from DB 219 and health module 206 contain critical API/microservice events that capture historical error rates of individual microservices, historical error rates of microservice chains, type of API call being made, number of retires to successfully complete the API call, error type, health status mapping, etc. Therefore, critical events included in application logs and health status mappings are logged/analyzed by knowledge base 208, wherein the logs and mappings are logged/stored in knowledge base 208, which may be a database), wherein the stored critical events are used to generate a defect summary report that provides detailed characteristics and associated intelligent events for in-depth automatic bug analysis (Kairali: Col 25, lines 31-36: reporting module 216 may report the predicted API call failure rate, confidence levels of the prediction, current log levels as reported by the proxies, failure types, and whether or not self-healing is possible. The report is used to instruct dynamic log level changer to increase, decrease, or retain current log levels of services 215 and/or proxies 217. Col 16, lines 24-35; Col 17, lines 19-44; Col 18, lines 21-49: stored critical events (historical error rates, API type, error type, mapping, etc.) are used to generate the failure rate prediction via knowledge base 208, which is an intelligent event (Col 19, lines 66-67: ML engine to make predictions). Thus, stored critical events are used to generate a failure prediction report that provides detailed characteristics containing the predicted API call failure rate, confidence levels, current log levels, failure type, ability to self-heal and associated intelligent events (ML-generated failure rate) for in-depth automatic bug analysis (whether to change or retain log levels)).
Regarding Claim 3, Kairali in view of StackOverflow teaches the method of claim 1, as referenced above, wherein the playback failure is tied to a blacked-out program during a program broadcast (StackOverflow: Page 1, error message image).
Regarding Claim 4, Kairali in view of StackOverflow teaches the method of claim 1, as referenced above, further comprising:
strategically enabling detailed logging for specific user sets (Kairali: Col 23, lines 43-50: increase additional logging for proxies 217) and temporal intervals (Kairali: Col 24, lines 5-16: enable detailed logging in DEBUG mode for threshold period of time in view of predicted failure rates).
Regarding Claim 5, Kairali in view of StackOverflow teaches the method of claim 1, further comprising:
using cloud-native logging to provide scalable and adaptive solutions for log management in distributed environments (Kairali: Fig. 2B and Col 24, lines 24-49: knowledge base 208 predicts high failure rate based on historical and current error rates and health mappings of M1-M2-M3 API call, where M3 uses a failing cloudant URL, and instructs dynamic log level changer 212 to increase log levels for each microservice 215 (M1-M2-M3). If another microservice chain M4-M5-M6 uses the same cloudant URL for a similar API call, log levels may be increased for those microservices as well. Col 16, lines 42-48; Col 17, lines 40-44; Col 18, lines 21-49: logs historical and current error rate and health mappings and provides logged data to knowledge base 208 to generate a prediction. As shown in Fig. 2B, computing environment 260 is a distributed computing environment connected by network 250. Thus, cloud-native logging is used to log the failing cloudant URL for failure prediction and provide scalable (towards similar microservices) and adaptive (towards detected failing cloudant URL) log adjustment/management in (distributed) computing environment 260).
Regarding Claim 6, Kairali in view of StackOverflow teaches the method of claim 1, as referenced above, wherein the dynamically adjusted log levels provide resource automatized logging (Kairali: Col 24, lines 1-16: dynamically adjusted log levels provide automized log level switching (e.g., INFO to DEBUG, DEBUG to INFO; resource == specific log level to provide different kinds of information; see Col 21, lines 54-64)).
Regarding Claim 7, Kairali in view of StackOverflow teaches the method of claim 1, wherein the defect log analyzer captures detailed information about specific errors encountered by different users (Kairali: Col 18, lines 21-30: knowledge base 208 receives and stores data extracted from DB 219 and health module 206. Col 16, lines 24-35: DB 219 contains metrics associated with user profiles such as error rates of individual microservices, error rates of microservice chains, the type of errors, warnings and failures, etc.).
Regarding Claim 9, Kairali in view of StackOverflow teaches the method of claim 1, as referenced above, wherein the defect learning period manager examines feedback on use case predictions and uses the feedback to refine and improve prediction algorithms (Kairali: Fig. 6A, step 612 and Col 26, lines 29-48: dynamic log level changer 212 examines the low confidence level of predicted error rate (Col 26, lines 18-22: of API call, wherein API call is a use case) from second AI module 204 and uses the confidence-threshold output to increase log level to improve the overall confidence of predictions made by the first AI module 202).
Regarding Claim 10, Kairali discloses a system (Fig. 1A-1B and Col 25, lines 43-48: method of Fig. 6A-6B implemented by computing system 100 of Fig. 1A-1B) comprising:
one or more processors (Fig. 1A: processor(s) 103); and
a memory device storing a set of instructions (Col 8, lines 5-16: memory 105 and persistent storage 106 storing programs, applications, processes, program instructions described herein and accessed by processor(s) 103) that, when executed by the one or more processors, causes the one or more processors to:
detect critical log errors in examined incoming logs that affect system performance (Fig. 6A, step 605-607 and Col 26, lines 8-11: knowledge base 208 checks and analyzes current error rates and historical error rates for microservice chain being invoked in API call. Col 17, lines 59-63: the examined current and historical error rates are incoming stored logs from DB 219 (Col 16, lines 20-35: historical DB 219) and health module 206 (Col 17, lines 19-44), wherein the detected error rates failed API system performance);
categorize failures associated with the detected critical log errors by revealing underlying patterns associated with the detected critical log errors (Fig. 6A, step 609-610 and Col 26, lines 11-22: knowledge base 208 analyzes current and historical error rates and predicts the error rate of the API call for the user profile invoking the API call. Col 19, lines 28-34: predicting involves categorizing a failing probability associated with the detected historical log errors by revealing underling failure patterns associated with the detected historical log errors (e.g., high likelihood of error if user 1 invokes microservice chain M1-M2-M3-M4 if microservice M4 is observed to be failing 90% of the time over last 24 hours when user 1 makes the API call));
identify use cases related to the categorized failures using root cause analysis of the underlying patterns, wherein the use cases are associated with user sets (Col 19, lines 25-42: knowledge base 208 identifies the microservice chain regularly invoked by an API call (“use case”) when categorizing/predicting error rates of the microservice chain using RCA of underlying patterns (e.g., microservice M4 observed to be failing 90% of the time; M4 identified as a root case for failed API call M1-M2-M3-M4 and contains failing pattern of 90% over last 24 hours when invoked by user 1));
identify specific user sets with a high probability of encountering other use cases that correlate with the identified use cases (Col 19, lines 25-42: knowledge base 208 predicts/identifies that the API call invoking M1-M2-M3-M4 (“identified use case”) will most likely fail for any existing users (e.g., user 1) and new users trying to invoke the same API call (“other (future) use cases));
dynamically adjust log levels for the specific user sets with the high probability of encountering the other use cases, based on the detected critical errors and the categorized failures (Fig. 6A, steps {610-11, 613, 617-619, 623-627, 631} and Col 27, lines 41-49: based on/after detecting critical historical log errors and categorized API failure rates in step 610, dynamic log level changer 212 of the second AI module 204 (“defect log level controller”) modifies the log levels of proxies 217 to increase the amount of information captured in the logs of application 203 invoking the service chain(s) in step 631 if current log levels are insufficient for the predicted error rate of the API call. Col 15, lines 34-40: proxies 217 direct requests to proper [individual microservice] 215, thus dynamically modifying log levels of proxies 217 also modifies log levels for users requesting the microservice chain (“other use cases”), wherein the requests are routed by proxies 217, based on the previously detected historical log errors and predicted failure rates));
in response to identified failure use cases, initiate a learning phase that includes training on user-attempted… failure and use a feedback loop that monitors system performance (Fig. 6A, steps 610-612 and Col 26, lines 28-48: in response to the predicted error rates (i.e., identified predicted failure of invoking/using the microservice chain) and if the error rate prediction made by first AI module 202 is not above a confidence threshold value, dynamic log level changer 212 modifies the log level applied to the proxies 217 to capture more log information collected by services 215 and/or proxies 217 of applications 203 to improve overall confidence of predictions made by the first AI module 202. As described above and in Col 16, lines 7-53, log information collected by proxies 217 and stored in DB 219 encompasses user-attempted failure as user requests are routed to corresponding services 215 by proxies 217 and information about the microservices invoked by the user are logged. Said information includes historical error rates, failures of API calls, users associated with errors and failures, etc. Fig. 6B, steps {633, 635 638, 639, 623} and Col 28 lines 24-29: learning phase interpreted as comprising a feedback loop from step 638 [Wingdings font/0xE0] 623 to check and report current log levels and determine whether current log levels are sufficient for the error rate (step 627-631; see above) for further adjustment (learn whether current log levels are sufficient and adjust via trial-and-error through determination and retry steps 627, 639));
dynamically adjust a duration of the learning phase based on a rate of change in user-attempted… failure (Fig. 6B, step 637 and Col 27, lines 59-65: over time, where the same API call is successful above a threshold amount of time as configured by the service mesh 211, the dynamic log level changer 212 may further adjust the log levels of proxies 217 by lowering log levels. Thus, a learning period duration (threshold time) was effectively previously set/adjusted by service mesh 211 in order to detect (“based on”) a rate of change from failed API call to successful API call (API call failure == “user attempted failure” as user invokes API call – see above)); and
in response to completing the learning phase, dynamically adjust log levels to refine system configuration (Fig. 6B, step {627, 629, 633, 635, 637} and Col 27, lines 30-40: in step 629, dynamic log levels are determined sufficient for predicted error rate. Col 27, lines 54-66: if the API call is successful above a threshold amount of time, the dynamic log level changer 212 may adjust log levels of proxies 217 by lowering log levels. Col 24, lines 9-16: log levels were previously increased from INFO to DEBUG in view of predicted failure rates. Lowering said levels after a threshold period of time may involve reverting the log level from DEBUG back to INFO, providing a different (more) detailed logging and analysis in INFO mode. Therefore, in response to meeting sufficient log levels for the error rate (wherein determination step encompasses “completing the learning/log level adjustment phase”), log levels are dynamically reduced upon a successful API call as further DEBUG logs are no longer necessary, refining relevant system log levels).
Kairali does not disclose:
…user-attempted playback failure…
However, StackOverflow teaches:
…user-attempted playback failure (Pages 1-2, initial question and 9/11/2020 comment: user executes YouTube iFrame API from the same IP/PC and encounters a playback error)…
Therefore, it would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to which said subject matter pertains to perform a simple substitution of one known element (Kairali: Col 16, lines 7-53; Col 19, lines 25-42: generic user executed API call, resulting in API call failure) for another (StackOverflow: Pages 1-2: user executes YouTube iFrame API call on same IP/PC, resulting in playback error) to obtain predictable results (user-initiated API failure).
Regarding Claim 11, Kairali in view of StackOverflow teaches the system of claim 10, as referenced above, wherein the system logs critical events that capture insights and stores the critical events in a database (Kairali: Col 17, lines 59-67: knowledge base 208 may be structured as a database and may be used to make predictions about API call failure fates using data extracted from service mesh metrics DB 219 (including application logs) and health status mappings provided by health module 206. Col 18, lines 21-30: knowledge base 208 receives and stores data extracted from DB 219 and health module 206. Col 16, lines 24-35 and Col 17, lines 19-44: data from DB 219 and health module 206 contain critical API/microservice events that capture historical error rates of individual microservices, historical error rates of microservice chains, type of API call being made, number of retires to successfully complete the API call, error type, health status mapping, etc. Therefore, critical events included in application logs and health status mappings are logged/analyzed by knowledge base 208, wherein the logs and mappings are logged/stored in knowledge base 208, which may be a database), wherein the stored critical events are used to generate a defect summary report that provides detailed characteristics and associated intelligent events for in-depth automatic bug analysis (Kairali: Col 25, lines 31-36: reporting module 216 may report the predicted API call failure rate, confidence levels of the prediction, current log levels as reported by the proxies, failure types, and whether or not self-healing is possible. The report is used to instruct dynamic log level changer to increase, decrease, or retain current log levels of services 215 and/or proxies 217. Col 16, lines 24-35; Col 17, lines 19-44; Col 18, lines 21-49: stored critical events (historical error rates, API type, error type, mapping, etc.) are used to generate the failure rate prediction via knowledge base 208, which is an intelligent event (Col 19, lines 66-67: ML engine to make predictions). Thus, stored critical events are used to generate a failure prediction report that provides detailed characteristics containing the predicted API call failure rate, confidence levels, current log levels, failure type, ability to self-heal and associated intelligent events (ML-generated failure rate) for in-depth automatic bug analysis (whether to change or retain log levels)).
Regarding Claim 12, Kairali in view of in view of StackOverflow teaches the system of claim 10, as referenced above, wherein the playback failure is tied to a blacked-out program during a program broadcast (StackOverflow: Page 1, error message image).
Regarding Claim 13, Kairali in view of in view of StackOverflow teaches the system of claim 10, as referenced above, wherein the system strategically enables detailed logging for specific user sets (Kairali: Col 23, lines 43-50: increase additional logging for proxies 217) and temporal intervals (Kairali: Col 24, lines 5-16: enable detailed logging in DEBUG mode for threshold period of time in view of predicted failure rates).
Regarding Claim 14, Kairali in view of in view of StackOverflow teaches the system of claim 10, as referenced above, wherein the system uses cloud-native logging to provide scalable and adaptive solutions for log management in distributed environments (Kairali: Fig. 2B and Col 24, lines 24-49: knowledge base 208 predicts high failure rate based on historical and current error rates and health mappings of M1-M2-M3 API call, where M3 uses a failing cloudant URL, and instructs dynamic log level changer 212 to increase log levels for each microservice 215 (M1-M2-M3). If another microservice chain M4-M5-M6 uses the same cloudant URL for a similar API call, log levels may be increased for those microservices as well. Col 16, lines 42-48; Col 17, lines 40-44; Col 18, lines 21-49: logs historical and current error rate and health mappings and provides logged data to knowledge base 208 to generate a prediction. As shown in Fig. 2B, computing environment 260 is a distributed computing environment connected by network 250. Thus, cloud-native logging is used to log the failing cloudant URL for failure prediction and provide scalable (towards similar microservices) and adaptive (towards detected failing cloudant URL) log adjustment/management in (distributed) computing environment 260).
Regarding Claim 15, Kairali in view of in view of StackOverflow teaches the system of claim 10, as referenced above, wherein the system dynamically adjusts log levels to provide resource automatized logging (Kairali: Col 24, lines 1-16: dynamically adjusted log levels provide automized log level switching (e.g., INFO to DEBUG, DEBUG to INFO; resource == specific log level to provide different kinds of information; see Col 21, lines 54-64)).
Regarding Claim 16, Kairali in view of in view of StackOverflow teaches the system of claim 10, as referenced above, wherein the system captures detailed information about specific errors encountered by different users (Kairali: Col 18, lines 21-30: knowledge base 208 receives and stores data extracted from DB 219 and health module 206. Col 16, lines 24-35: DB 219 contains metrics associated with user profiles such as error rates of individual microservices, error rates of microservice chains, the type of errors, warnings and failures, etc.).
Regarding Claim 18, Kairali in view of in view of StackOverflow teaches the system of claim 10, as referenced above, wherein the system examines feedback on use case predictions and uses the feedback to refine and improve prediction algorithms. (Kairali: Fig. 6A, step 612 and Col 26, lines 29-48: dynamic log level changer 212 examines the low confidence level of predicted error rate (Col 26, lines 18-22: of API call, wherein API call is a use case) from second AI module 204 and uses the confidence-threshold output to increase log level to improve the overall confidence of predictions made by the first AI module 202).
Regarding Claim 19, Kairali discloses a method of defect navigation of a logging system (Fig 6A-6B and Col 25, lines 55-57: method 600 for dynamically managing application log levels within a service mesh 211 based on predicted failure rates (step 610 – defect/failure navigation), the method comprising:
detecting critical log errors in examined incoming logs that affect system performance (Fig. 6A, step 605-607 and Col 26, lines 8-11: knowledge base 208 checks and analyzes current error rates and historical error rates for microservice chain being invoked in API call. Col 17, lines 59-63: the examined current and historical error rates are incoming stored logs from DB 219 (Col 16, lines 20-35: historical DB 219) and health module 206 (Col 17, lines 19-44), wherein the detected error rates indicate failed API system performance);
categorizing failures associated with the detected critical log errors by revealing underlying patterns associated with the detected critical log errors (Fig. 6A, step 609-610 and Col 26, lines 11-22: knowledge base 208 analyzes current and historical error rates and predicts the error rate of the API call for the user profile invoking the API call. Col 19, lines 28-34: predicting involves categorizing a failing probability associated with the detected historical log errors by revealing underling failure patterns associated with the detected historical log errors (e.g., high likelihood of error if user 1 invokes microservice chain M1-M2-M3-M4 if microservice M4 is observed to be failing 90% of the time over last 24 hours when user 1 makes the API call));
identifying use cases related to the categorized failures using root cause analysis of the underlying patterns, wherein the use cases are associated with user sets (Col 19, lines 25-42: knowledge base 208 identifies the microservice chain regularly invoked by an API call (“use case”) when categorizing/predicting error rates of the microservice chain using RCA of underlying patterns (e.g., microservice M4 observed to be failing 90% of the time; M4 identified as a root case for failed API call M1-M2-M3-M4 and contains failing pattern of 90% over last 24 hours when invoked by user 1));
identifying specific user sets with a high probability of encountering other use cases that correlate with the identified use cases (Col 19, lines 25-42: knowledge base 208 (also a “defect similar user set system”) predicts/identifies that the API call invoking M1-M2-M3-M4 (“identified use case”) will most likely fail for any existing users (e.g., user 1) and new users trying to invoke the same API call (“other (future) use cases));
dynamically adjusting log levels for the specific user sets with a high probability of encountering the other use cases, based on the detected critical errors and the categorized failures (Fig. 6A, steps {610-11, 613, 617-619, 623-627, 631} and Col 27, lines 41-49: based on/after detecting critical historical log errors and categorized API failure rates in step 610, dynamic log level changer 212 of the second AI module 204 (“defect log level controller”) modifies the log levels of proxies 217 to increase the amount of information captured in the logs of application 203 invoking the service chain(s) in step 631 if current log levels are insufficient for the predicted error rate of the API call. Col 15, lines 34-40: proxies 217 direct requests to proper [individual microservice] 215, thus dynamically modifying log levels of proxies 217 also modifies log levels for users requesting the microservice chain (“other use cases”), wherein the requests are routed by proxies 217, based on the previously detected historical log errors and predicted failure rates));
initiating a learning phase that employs a feedback loop and monitors system performance (Fig. 6A, steps 610-612 and Col 26, lines 28-48: in response to the predicted error rates (i.e., identified predicted failure of invoking/using the microservice chain) and if the error rate prediction made by first AI module 202 is not above a confidence threshold value, dynamic log level changer 212 modifies the log level applied to the proxies 217 to capture more log information collected by services 215 and/or proxies 217 of applications 203 to improve overall confidence of predictions made by the first AI module 202. As described above, log information collected by proxies 217 encompasses user behavior as user requests are routed to corresponding services 215 by proxies 217 and information about the microservices invoked by the user are logged. Fig. 6B, steps {633, 635 638, 639, 623} and Col 28 lines 24-29: learning phase interpreted as comprising a feedback loop from step 638 [Wingdings font/0xE0] 623 to check and report current log levels and determine whether current log levels are sufficient for the error rate (step 627-631; see above) for further adjustment (learn whether current log levels are sufficient and adjust via trial-and-error through determination and retry steps 627, 639));
dynamically adjusting a duration of the learning phase based on a rate of change in user-attempted… failure (Fig. 6B, step 637 and Col 27, lines 59-65: over time, where the same API call is successful above a threshold amount of time as configured by the service mesh 211, the dynamic log level changer 212 may further adjust the log levels of proxies 217 by lowering log levels. Thus, a learning period duration (threshold time) was effectively previously set/adjusted by service mesh 211 in order to detect (“based on”) a rate of change from failed API call to successful API call (API call failure == “user-attempted failure” as user invokes API call – see above)); and
in response to completing the learning phase, dynamically adjusting log levels (Fig. 6B, step {627, 629, 633, 635, 637} and Col 27, lines 30-40: in step 629, dynamic log levels are determined sufficient for predicted error rate. Col 27, lines 54-66: if the API call is successful above a threshold amount of time, the dynamic log level changer 212 may adjust log levels of proxies 217 by lowering log levels. Col 24, lines 9-16: log levels were previously increased from INFO to DEBUG in view of predicted failure rates. Lowering said levels after a threshold period of time may involve reverting the log level from DEBUG back to INFO, providing a different (more) detailed logging and analysis in INFO mode. Therefore, in response to meeting sufficient log levels for the error rate (wherein determination step encompasses “completing the learning/log level adjustment phase”), log levels are dynamically reduced upon a successful API call).
Kairali does not disclose:
…user-attempted playback failure…
However, StackOverflow teaches:
…user-attempted playback failure (Pages 1-2, initial question and 9/11/2020 comment: user executes YouTube iFrame API from the same IP/PC and encounters a playback error)…
Therefore, it would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to which said subject matter pertains to perform a simple substitution of one known element (Kairali: Col 16, lines 7-53; Col 19, lines 25-42: generic user executed API call, resulting in API call failure) for another (StackOverflow: Pages 1-2: user executes YouTube iFrame API call on same IP/PC, resulting in playback error) to obtain predictable results (user-initiated API failure).
Claims 8 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Kairali in view of StackOverflow, in further view of Shemer at al. (US 20220029902 A1, hereinafter “Shemer”).
Regarding Claim 8, Kairali in view of StackOverflow the method of claim 1, as referenced above.
Kairali in view of StackOverflow does not teach:
wherein the defect use case identifier segregates users based on one or more attributes including user type, location, channel type, and error type.
However, Shemer teaches:
wherein the defect use case identifier segregates users based on one or more attributes including user type, location, channel type, and error type ([0084]: additional users or entities affected by the network anomaly can be identified. For example, if an anomaly is detected in a particular type of user or geographic area, similarly situated users/entities/VMs can be checked for the same network anomaly. Moreover, if 90% of anomalous VMs go through a VPN, VMs sharing those characteristics can be identified as affected, resulting in generating VM profiles to verify other VMs suffering from the same event. Users are interpreted as users and end devices such as VMs, wherein users are segregated (identified over the other) based on user type, geographic area, channel type (VPN or not), and error type (same anomalous event)).
Therefore, it would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to which said subject matter pertains to combine Kairali, StackOverflow, and Shemer by implementing the user/device-based anomaly detection taught by Shemer. One of ordinary skill in the art would be motivated to make this modification in order to pinpoint the root cause of the anomalous event (Shemer: [0084]).
Regarding Claim 17, Kairali in view of StackOverflow the system of claim 10, as referenced above.
Kairali in view of StackOverflow does not teach:
wherein the system segregates users based on one or more attributes including user type, location, channel type, and error type.
However, Shemer teaches:
wherein the system segregates users based on one or more attributes including user type, location, channel type, and error type ([0084]: additional users or entities affected by the network anomaly can be identified. For example, if an anomaly is detected in a particular type of user or geographic area, similarly situated users/entities/VMs can be checked for the same network anomaly. Moreover, if 90% of anomalous VMs go through a VPN, VMs sharing those characteristics can be identified as affected, resulting in generating VM profiles to verify other VMs suffering from the same event. Users are interpreted as users and end devices such as VMs, wherein users are segregated (identified over the other) based on user type, geographic area, channel type (VPN or not), and error type (same anomalous event)).
Therefore, it would have been obvious before the effective filing date of the claimed invention to one of ordinary skill in the art to which said subject matter pertains to combine Kairali, StackOverflow, and Shemer by implementing the user/device-based anomaly detection taught by Shemer. One of ordinary skill in the art would be motivated to make this modification in order to pinpoint the root cause of the anomalous event (Shemer: [0084]).
Response to Arguments
Applicant’s arguments with respect to 35 U.S.C. 102/103 of claim(s) 1-19 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.
Newly cited art StackOverflow teaches the amended limitations of a “user-attempted playback failure” (claims 1, 10, 19) and “[the] playback failure is tied to a blacked-out program during a program broadcast” (claims 3, 12), respectively. Please see above for more detail.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CATHERINE MARIE NGUYEN whose telephone number is (571)272-6160. The examiner can normally be reached M-F 7:30 AM - 4:30 PM ET.
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 at (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 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.
/C.M.N./Examiner, Art Unit 2114
/JOSEPH R KUDIRKA/Primary Patent Examiner, Art Unit 2114
Prosecution Insights