DETAILED ACTION
This office action is in response to application filed on 8/29/2023.
Claims 1 – 20 are pending.
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 .
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, 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.
Claim(s) 1 – 5, 8 – 12 and 15 – 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Das Gupta et al (US 20130311622, prior art part of IDS dated 11/4/2024, hereinafter Das Gupta), in view of Liu (US 20180121226), and further in view of Subbarayan et al (US 20190114417, hereinafter Subbarayan).
As per claim 1, Das Gupta discloses: A computer-implemented method comprising:
identifying, using a computer processor, each [application] within a proxy server; (Das Gupta figure 2 and [0034]: “for each of multiple applications running on Application Server 7”.)
determining, using the computer processor, a regression model corresponding to each [application], the regression model defining a response time of each [application] based at least in part on a set of available response time predictors; (Das Gupta [0026]: “The application specific and dedicated transaction timeout values may be changed by analyzing the current behavior of an application transaction to provide real time adjustment of transaction timeout values. The timeout value may be adjusted for each application based upon earlier performance of similar transactions based upon the learning of the script from previous failures”; [0034]: “Transaction Timeout Calculator 15 acts to dynamically and automatically adjust the transaction timeout values for each of multiple applications running on Application Server 7 in an embodiment of the invention, taking into account, for example, the behavioral pattern of each deployed application during particular days or at particular times of the day with respect to the number of queries executed and how "heavy" each query is. The runtime for an application may further be adjusted based upon variables, such as, record size, network speed, current database status, server load and any of a variety of other variable characteristics including past performance reflected in the script from previous failures.”)
sequentially predicting a response time corresponding to each microservice in the sequence using the corresponding regression model; and updating, using the computer processor, a timeout value of the predicted REST API call within the proxy server based on the sequentially predicted response times. (Das Gupta [0026]: “The application specific and dedicated transaction timeout values may be changed by analyzing the current behavior of an application transaction to provide real time adjustment of transaction timeout values. The timeout value may be adjusted for each application based upon earlier performance of similar transactions based upon the learning of the script from previous failures where there may have been a timeout due to the fact that the transaction timeout was not near optimal… The initial value for a transaction timeout is set as default based upon the initially available knowledge regarding network and database characteristics (e.g. network speed and database schema complexity). The timeout values may be dynamically adjusted based upon current network speed and database execution time for the most frequently executed queries. Whenever a timeout occurs, the script automatically appends a time to the existing transaction timeout value. The script acts to poll the frequency of timeout error which information is used to predict when the next timeout may occur. The next timeout may also be predicted from historical knowledge of the expected level of application usage at a particular time and day.”)
Das Gupta did not explicitly disclose:
Wherein the applications comprises microservices;
and mapping a topology of microservices within the proxy server, the topology including each microservice within the proxy server and each representational state transfer (REST) application programming interface (API) calling relationship between each microservice and each other microservice, and wherein the topology identifies one of an application layer, a middleware layer, and an infrastructure layer corresponding to each microservice;
building a sequence model for at least one microservice corresponding to the application layer; predicting an incoming REST API call and identifying a probable sequence model corresponding to the predicted incoming REST API call using the computer processor;
However, Liu teaches:
and mapping a topology of microservices within the proxy server, the topology including each microservice within the proxy server and each representational state transfer (REST) application programming interface (API) calling relationship between each microservice and each other microservice, (Liu [0136]: “According to the method for discovering an application topology relationship provided by this application, in a packet transmission process, API calling information is recorded, and whether interaction exists between two virtual machines corresponding to two sets of API calling information is determined by matching whether the two sets of API calling information meet a first condition. By using the foregoing manner, a topology discovery server may determine interaction frequency, involved in collected API calling information, of virtual machines, and an application topology relationship between the virtual machines is determined according to the interaction frequency of the virtual machines.”; [0139]: “The topology discovery server 81 is configured to collect at least two sets of application programming interface API calling information, where each set of API calling information corresponds to one API call, and each set of API calling information includes an identifier of a virtual machine corresponding to the API call, an occurrence time of the API call, and a packet flow direction of the API call.”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Liu into that of Das Gupta in order to map a topology of microservices within the proxy server, the topology including each microservice within the proxy server and each representational state transfer (REST) application programming interface (API) calling relationship between each microservice and each other microservice. Das Gupta [0026] teaches determining and updating application specific and dedicated transaction timeout values, Liu [0136] has shown that discovery of a topology relationship is crucial to accurately determine API call information. It would have been obvious for one of ordinary skill in the art to enhance the prediction and modification of application specific transaction timeout value, using the known techniques of mapping out topology relationship of API call of the application/microservice in order to gain the commonly understood benefits of such an adaption, and is therefore rejected under 35 USC 103.
Subbarayan teaches:
wherein the applications comprises microservices; and wherein the topology identifies one of an application layer, a middleware layer, and an infrastructure layer corresponding to each microservice; (Subbarayan [0043]: “The data logger 251 can be configured to receive a copy of incoming data from the router 250 and log the data for reference… data logger 251 can be configured to parse the data into individual layers of encapsulation and suitably log data corresponding to one or more layers of interest. For example, in some embodiments, the data logger 251 can be configured to log data corresponding to Layer 7 or the Application layer, including information related to API traffic. In some other embodiments, as another example, the data logger 251 can log data corresponding to other layers such as the Layer 3 (Network Layer) or Layer 4 (Transport Layer), etc.”)
building a sequence model for at least one microservice corresponding to the application layer; predicting an incoming REST API call and identifying a probable sequence model corresponding to the predicted incoming REST API call using the computer processor; (Subbarayan [0045]: REST API; [0052]: “the proxy server 220 can receive a sequence 51 of API calls. The ML model 253 can receive an indication of at least one API call in the sequence 51 of API calls (also referred to herein as symbols) and predict a sequence of API calls P1 expected to be associated with the indication of the at least one API call provided as input, under normal conditions of API traffic.”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Subbarayan into that of Das Gupta and Liu in order to have the applications comprises microservices; and wherein the topology identifies one of an application layer, a middleware layer, and an infrastructure layer corresponding to each microservice, and building a sequence model for at least one microservice corresponding to the application layer; predicting an incoming REST API call and identifying a probable sequence model corresponding to the predicted incoming REST API call using the computer processor. Das Gupta [0026] teaches determining and updating application specific and dedicated transaction timeout values, Subbarayan [0052] teaches predict a sequence of API calls P1 expected to be associated with the indication of the at least one API call provided as input. It would have been obvious for one of ordinary skill in the art to enhance the prediction and modification of application specific transaction timeout value taught by Das Gupta, using the known techniques of predicting future API call and call sequence order to gain the commonly understood benefits of such an adaption, such as enhanced prediction and determining of specific timeout value, and is therefore rejected under 35 USC 103.
As per claim 2, the combination of Das Gupta, Liu and Subbarayan further teach:
The computer-implemented method of claim 1, wherein the set of available response time predictors includes real-time resources, REST API parameter information, and a downstream time duration of the REST API call. (Subbarayan [0052])
As per claim 3, the combination of Das Gupta, Liu and Subbarayan further teach:
The computer-implemented method of claim 1, wherein building a sequence model for at least one microservice corresponding to the application layer comprises building a sequence model for each microservice corresponding to the application layer. (Subbarayan [0046]: “The context analyzer 252 can define a set of symbols, the symbol being units of the data associated with the sequence of API transactions. The context analyzer 252 can further define a set of contexts based on the occurrence of the symbols. Each sequence can be defined with consistency of symbols in a context. The contexts can be dynamic and based on the applications. For example, the context analyzer 252 can extract a sequence of API calls (e.g., API Sequence S1={login, view account balance, view payee, initiate money transfer, validate transaction, store transaction number and logout}) associated with a particular API, and define symbols such that each API call in the sequence is associated with a different symbol. In some instances, the symbols may be defined based on the function of each of the API calls, the type of the API call, and/or the protocol associated with the API call. For example, an API call including a get request associated with a login via a HTTP protocol may be associated with a different symbol compared to an API call with a put request associated with a login via a HTTTPS protocol.”)
As per claim 4, the combination of Das Gupta, Liu and Subbarayan further teach:
The computer-implemented method of claim 3, wherein each sequence model is constructed by the processor according to historical data. (Das Gupta [0026]: “The script acts to poll the frequency of timeout error which information is used to predict when the next timeout may occur. The next timeout may also be predicted from historical knowledge of the expected level of application usage at a particular time and day.”)
As per claim 5, the combination of Das Gupta, Liu and Subbarayan further teach:
The computer-implemented method of claim 4, wherein the historical data includes available memory, disk usage, CPU usage, network throughput of the proxy server. (Das Gupta [0039]: “Intelligent Progressive Increment Module 41 in FIG. 3 first determines if the timeout event is a multiple timeout event or a single timeout event. For a single timeout, it applies a fixed increase to the timeout by invoking Timeout Setter Module 37. For a multiple timeout event, it acts to determine a pattern (combination of the queries running, network utilization, CPU load, log file size, application running, number of open database connections and other factors) which caused the multiple timeout to occur. It stores this knowledge in a database so that when a similar pattern appears in future, the timeout can be readjusted by the Continuous Timeout Computation Module. It then calculates an appropriate timeout increase based on the severity of the situation (e.g. CPU load is alarmingly high).”)
As per claim 8, Das Gupta discloses: A method comprising:
identifying, using a computer processor, each [application] within a proxy server; (Das Gupta figure 2 and [0034]: “for each of multiple applications running on Application Server 7”.)
determining, using the computer processor, a regression model corresponding to each [application], the regression model defining a response time of each [application] based at least in part on a set of available response time predictors; (Das Gupta [0026]: “The application specific and dedicated transaction timeout values may be changed by analyzing the current behavior of an application transaction to provide real time adjustment of transaction timeout values. The timeout value may be adjusted for each application based upon earlier performance of similar transactions based upon the learning of the script from previous failures”; [0034]: “Transaction Timeout Calculator 15 acts to dynamically and automatically adjust the transaction timeout values for each of multiple applications running on Application Server 7 in an embodiment of the invention, taking into account, for example, the behavioral pattern of each deployed application during particular days or at particular times of the day with respect to the number of queries executed and how "heavy" each query is. The runtime for an application may further be adjusted based upon variables, such as, record size, network speed, current database status, server load and any of a variety of other variable characteristics including past performance reflected in the script from previous failures.”)
sequentially predicting a response time corresponding to each microservice in the sequence using the corresponding regression model; and updating, using the computer processor, a timeout value of the predicted REST API call within the proxy server based on the sequentially predicted response times. (Das Gupta [0026]: “The application specific and dedicated transaction timeout values may be changed by analyzing the current behavior of an application transaction to provide real time adjustment of transaction timeout values. The timeout value may be adjusted for each application based upon earlier performance of similar transactions based upon the learning of the script from previous failures where there may have been a timeout due to the fact that the transaction timeout was not near optimal… The initial value for a transaction timeout is set as default based upon the initially available knowledge regarding network and database characteristics (e.g. network speed and database schema complexity). The timeout values may be dynamically adjusted based upon current network speed and database execution time for the most frequently executed queries. Whenever a timeout occurs, the script automatically appends a time to the existing transaction timeout value. The script acts to poll the frequency of timeout error which information is used to predict when the next timeout may occur. The next timeout may also be predicted from historical knowledge of the expected level of application usage at a particular time and day.”)
Das Gupta did not explicitly disclose:
Wherein the applications comprises microservices;
and mapping a topology of microservices within the proxy server, assigning each microservice to one of an application layer, a middleware layer and an infrastructure layer of the proxy server; defining each representational state transfer (REST) application programming interface (API) calling relationship between each microservice and each other microservice within the proxy server;
building a sequence model for at least one microservice corresponding to the application layer; predicting an incoming REST API call and identifying a probable sequence model corresponding to the predicted incoming REST API call using the computer processor;
However, Liu teaches:
and mapping a topology of microservices within the proxy server, defining each representational state transfer (REST) application programming interface (API) calling relationship between each microservice and each other microservice within the proxy server; , (Liu [0136]: “According to the method for discovering an application topology relationship provided by this application, in a packet transmission process, API calling information is recorded, and whether interaction exists between two virtual machines corresponding to two sets of API calling information is determined by matching whether the two sets of API calling information meet a first condition. By using the foregoing manner, a topology discovery server may determine interaction frequency, involved in collected API calling information, of virtual machines, and an application topology relationship between the virtual machines is determined according to the interaction frequency of the virtual machines.”; [0139]: “The topology discovery server 81 is configured to collect at least two sets of application programming interface API calling information, where each set of API calling information corresponds to one API call, and each set of API calling information includes an identifier of a virtual machine corresponding to the API call, an occurrence time of the API call, and a packet flow direction of the API call.”;)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Liu into that of Das Gupta in order to map a topology of microservices within the proxy server, the topology including each microservice within the proxy server and each representational state transfer (REST) application programming interface (API) calling relationship between each microservice and each other microservice. Das Gupta [0026] teaches determining and updating application specific and dedicated transaction timeout values, Liu [0136] has shown that discovery of a topology relationship is crucial to accurately determine API call information. It would have been obvious for one of ordinary skill in the art to enhance the prediction and modification of application specific transaction timeout value, using the known techniques of mapping out topology relationship of API call of the application/microservice in order to gain the commonly understood benefits of such an adaption, and is therefore rejected under 35 USC 103.
Subbarayan teaches:
wherein the applications comprises microservices; assigning each microservice to one of an application layer, a middleware layer and an infrastructure layer of the proxy server; (Subbarayan [0043]: “The data logger 251 can be configured to receive a copy of incoming data from the router 250 and log the data for reference… data logger 251 can be configured to parse the data into individual layers of encapsulation and suitably log data corresponding to one or more layers of interest. For example, in some embodiments, the data logger 251 can be configured to log data corresponding to Layer 7 or the Application layer, including information related to API traffic. In some other embodiments, as another example, the data logger 251 can log data corresponding to other layers such as the Layer 3 (Network Layer) or Layer 4 (Transport Layer), etc.”; [0068]: application layer.)
building a sequence model for at least one microservice corresponding to the application layer; predicting an incoming REST API call and identifying a probable sequence model corresponding to the predicted incoming REST API call using the computer processor; (Subbarayan [0045]: REST API; [0052]: “the proxy server 220 can receive a sequence 51 of API calls. The ML model 253 can receive an indication of at least one API call in the sequence 51 of API calls (also referred to herein as symbols) and predict a sequence of API calls P1 expected to be associated with the indication of the at least one API call provided as input, under normal conditions of API traffic.”)
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teaching of Subbarayan into that of Das Gupta and Liu in order to have the applications comprises microservices; and wherein the topology identifies one of an application layer, a middleware layer, and an infrastructure layer corresponding to each microservice, and building a sequence model for at least one microservice corresponding to the application layer; predicting an incoming REST API call and identifying a probable sequence model corresponding to the predicted incoming REST API call using the computer processor. Das Gupta [0026] teaches determining and updating application specific and dedicated transaction timeout values, Subbarayan [0052] teaches predict a sequence of API calls P1 expected to be associated with the indication of the at least one API call provided as input. It would have been obvious for one of ordinary skill in the art to enhance the prediction and modification of application specific transaction timeout value taught by Das Gupta, using the known techniques of predicting future API call and call sequence order to gain the commonly understood benefits of such an adaption, such as enhanced prediction and determining of specific timeout value, and is therefore rejected under 35 USC 103.
As per claim 9, the combination of Das Gupta, Liu and Subbarayan further teach:
The method of claim 8, wherein the set of available response time predictors includes real-time resources, REST API parameter information, and a downstream time duration of the REST API call. (Subbarayan [0052])
As per claim 10, the combination of Das Gupta, Liu and Subbarayan further teach:
The method of claim 8, wherein building a sequence model for at least one application layer microservice comprises building a distinct sequence model for each application layer microservice. (Subbarayan [0046]: “The context analyzer 252 can define a set of symbols, the symbol being units of the data associated with the sequence of API transactions. The context analyzer 252 can further define a set of contexts based on the occurrence of the symbols. Each sequence can be defined with consistency of symbols in a context. The contexts can be dynamic and based on the applications. For example, the context analyzer 252 can extract a sequence of API calls (e.g., API Sequence S1={login, view account balance, view payee, initiate money transfer, validate transaction, store transaction number and logout}) associated with a particular API, and define symbols such that each API call in the sequence is associated with a different symbol. In some instances, the symbols may be defined based on the function of each of the API calls, the type of the API call, and/or the protocol associated with the API call. For example, an API call including a get request associated with a login via a HTTP protocol may be associated with a different symbol compared to an API call with a put request associated with a login via a HTTTPS protocol.”)
As per claim 11, the combination of Das Gupta, Liu and Subbarayan further teach:
The method of claim 10, wherein each sequence model is constructed according to historical data. (Das Gupta [0026]: “The script acts to poll the frequency of timeout error which information is used to predict when the next timeout may occur. The next timeout may also be predicted from historical knowledge of the expected level of application usage at a particular time and day.”)
As per claim 12, the combination of Das Gupta, Liu and Subbarayan further teach:
The method of claim 11, wherein the historical data includes available memory, disk usage, CPU usage, network throughput of the proxy server. (Das Gupta [0039]: “Intelligent Progressive Increment Module 41 in FIG. 3 first determines if the timeout event is a multiple timeout event or a single timeout event. For a single timeout, it applies a fixed increase to the timeout by invoking Timeout Setter Module 37. For a multiple timeout event, it acts to determine a pattern (combination of the queries running, network utilization, CPU load, log file size, application running, number of open database connections and other factors) which caused the multiple timeout to occur. It stores this knowledge in a database so that when a similar pattern appears in future, the timeout can be readjusted by the Continuous Timeout Computation Module. It then calculates an appropriate timeout increase based on the severity of the situation (e.g. CPU load is alarmingly high).”)
As per claim 15, it is the system variant of claim 8 and is therefore rejected under the same rationale. (Das Gupta figure 1: application server.)
As per claim 16, it is the system variant of claim 9 and is therefore rejected under the same rationale.
As per claim 17, it is the system variant of claim 10 and is therefore rejected under the same rationale.
As per claim 18, it is the system variant of claim 11 and is therefore rejected under the same rationale.
As per claim 19, it is the system variant of claim 12 and is therefore rejected under the same rationale.
As per claim 20, it is the computer program product variant of claim 8 and is therefore rejected under the same rationale. (Das Gupta [0018]: CRM.)
Allowable Subject Matter
Claims 6, 7, 13 and 14 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Shen et al (US 20240007492) teaches “a customer's infrastructure may be fortified by leveraging deep learning technology (e.g., an encoder-decoder machine-learning (ML) model) to predict events in the cloud environment. During a training phase, the ML model may be trained to make a prediction regarding a next event based on a predetermined or configurable length of a sequence of contextual events. For example, historical events (e.g., cloud application programming interface (API) events logged to a cloud activity trace) observed within the customer's cloud infrastructure over the course of a particular date range may be split into appropriate event/context pairs and fed to the ML model. Subsequently, during a run-time anomaly detection phase, the ML model may be used to predict a next event based on a sequence of immediately preceding events to facilitate identification of anomalous activity.”
Pasquini et al (US 20190057016) teaches “A front-end application flow, including at least one call to one or more business services flows, and one or more business services flows, each including one or more calls to application program interfaces (APIs), are received at a processor and the processor compiles a complete end-to-end flow that includes the front-end application flow and the one or more business services flows. The complete end-to-end flow is expressed in ordered terms of the one or more business services flows and the one or more calls to the APIs. A projected latency for the complete end-to-end flow is automatically constructed by the processor by totaling response times for each of the one or more calls to the APIs included in the complete end-to-end flow.”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES M SWIFT whose telephone number is (571)270-7756. The examiner can normally be reached Monday - Friday: 9:30 AM - 7PM.
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, April Blair can be reached at 5712701014. 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.
/CHARLES M SWIFT/ Primary Examiner, Art Unit 2196