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 .
DETAILED ACTION
1. This Office Action is in response to the application filed on 07/25/2024. Claims 1-20 are pending in this application. Claims 1, 12 and 20 are independent claims.
Claim Objections
2. Claims 1-20 are objected to because of the following informalities: the claim limitation such as “a corresponding PTS (PTS)” in Claims 1, 12 and 20 needs to be spelled out as “a corresponding performance test services (PTS)” according to the specification, par 17. Claims 2 and 13 need indentation. Also, the limitation such as “an performance test Application Programming Interface call” from Claim 11 should be changed to “a performance test Application Programming Interface call”. Claims 2-11 and 13-19 are also objected for incorporating the deficiency of their independent claims 1 and 12 respectively. Appropriate correction is required.
Claim Rejections - 35 USC § 101
3. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
4. Claim 20 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim 20 does not fall within at least one of the four categories of patent eligible subject matter because claim 20 is subject to signal per se. According to the specification, par 89, the computer readable medium of the claim 20 can be interpreted as a signal with BRI. Even though the following specification attempts to clarify that the computer-readable media comprise computer-readable storage media and communication media where the computer-readable storage media is non-transitory. The description/definition was provided as an example without limitation as follows. Thus, the examiner raises the 101 rejection on the product claim 20 as it does not fit into one of the statutory subject matter.
Par 89, Example computer-readable media may be, but are not limited to, a flash memory drive, digital versatile disc (DVD), compact disc (CD), fixed (hard) drive, diskette, optical disk, magnetic tape, semiconductor memory such as read-only memory (ROM), and/or any transmitting/receiving medium such as the Internet or other communication network or link. By way of example and not limitation, computer-readable media comprise computer-readable storage media and communication media. Computer-readable storage media are tangible and non-transitory and store information such as computer-readable instructions, data structures, program modules, and other data. Communication media, in contrast, typically embody computer-readable instructions, data structures, program modules, or other data in a transitory modulated signal such as a carrier wave or other transport mechanism and include any information delivery media. Combinations of any of the above are also included in the scope of computer-readable media.
Claim Rejections - 35 USC § 103
5. 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.
6. 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.
7. Claims 1, 4, 11, 12, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kaitha (US PGPub 20210049093), in view of Sirota (US PGPub 20150135185), and further in view of Massa (US PGPub 20160014238).
As per Claim 1, Kaitha teaches of a system for automated performance test orchestration in a containerized environment, comprising: one or more processors programmed to: receive a performance test request to perform an automated performance test from among a plurality of types of automated performance tests, each type of automated performance test from among the plurality of automated performance tests being executed by a corresponding PTS (PTS); (Par 19, test system 100 receives a request to execute a performance test on an application. Performance tests may determine the speed, responsiveness and stability of a computer, network, software program or device under a workload. Performance testing may be executed in a production or test environment. Types of performance testing may include but are not limited to: load testing, stress testing, soak testing, spike testing, breakpoint testing, configuration testing, isolation testing, internet testing, and/or the like. Performance tests may monitor whether an application is meeting specified performance requirements. The performance requirements may be related to concurrency and throughput, server response time, render response time, performance specifications, and/or the like. Par 20, The request received by test system 100 may include a specified configuration and specified test data. The specified configuration may include specified set of servers 122, computing clusters 124, and applications 126.)
invoke, based on the performance test request, a PTS, from among a plurality of PTSs, to execute the automated performance test; (Par 14, The system may execute a performance test of an application in a test environment, monitor the results of the test, reconfigure the test environment, test data, and/or test script to optimize the performance test, and re-execute the performance test of the application in an updated test environment, test data, and/or test script to optimize the performance test. Par 90, Computer system 700 may be a client or server, accessing or hosting any applications and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software (“on-premise” cloud-based solutions); “as a service” models [performance test services/PTS].)
instantiate, by the PTS, one or more [dynamic] clusters to each perform one or more operations for the automated performance test, (Par 20, The specified configuration may include specified set of servers 122, computing clusters 124, and applications 126. Par 21, For example, to set up the test environment, environment engine 106 provisions computing resources in a cloud computing environment. The computing resources include servers 122, computing clusters 124, and application 126.)
Kaitha does not specifically teach, however Sirota teaches of each of the one or more dynamic clusters comprising: (i) a dynamic client instance, or (ii) a dynamic client instance and one or more dynamic server instances; (Par 26, dynamically modify a cluster at the current time (or at a different specified future time) [dynamic cluster] by adding and/or removing an indicated quantity of computing nodes [dynamic clients] (optionally with an indication of whether the computing nodes are to be auxiliary computing nodes and/or core computing nodes, Par 48, Furthermore, the computing nodes 120 in this example are separated into multiple different pools 215 of computing nodes that may each act as a distinct source of computing nodes for various client clusters, with each pool having differing associated prices for using its computing nodes and/or having other differing use conditions related to using its computing nodes. (e.g., to allow clients to use their own dedicated use computing nodes within their own clusters, such as for an ongoing fee that is less than a fee for using other on-demand computing nodes))
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective
filing date of the claimed invention to add each of the one or more dynamic clusters comprising: (i) a dynamic client instance, or (ii) a dynamic client instance and one or more dynamic server instances, as conceptually seen from the teaching of Sirota, into that of Kaitha because this modification can help spin up or shut down clients and servers by preventing wasted computer resources with high resilience while adapting scalability due to the network traffic.
Neither Kaitha nor Sirota specifically teaches, however Massa teaches to perform client-side load balancing to allocate resources to conduct the automated performance test; (Par 3, Load testing, as described above, is useful for testing the performance of software applications, databases, networks, client-side processing, load balancing utilities, and other systems and programs. Par 46, The load Testing Tool 400 may be a computer that simulates the load generated (such as by the Client 100) on the Server 300. The load Testing Tool 400 is illustrated in FIG. 1 as a single computer simulating a single client. However, the load Testing Tool 400 may simulate many clients if necessary to test the load on the Server 300. For example, the load Testing Tool 400 maybe more than one computer, each simulating the load generated by a client. The load Testing Tool 400 may also be a single computer simulating more than one virtual client, each virtual client simulating the load generated on the Server 300. Par 47, While simulating the load on the Server 300 generated by clients, the load Testing Tool 400 receives responses from the Server 300 that are used to analyze the effect of the simulated load on the Server 300.)
execute the automated performance test based on the invoked PTS, the one or more dynamic clusters, and the client-side load balancing; and (Abstract: The Load Testing Tool utilizes the script created with the messages converted by the Translation Tool to generate emulated messages to test and evaluate the performance of the client/server system. Par 3, Load testing, as described above, is useful for testing the performance of software applications, databases, networks, client side processing, load balancing utilities, and other systems and programs)
generate a result of the executed automated performance test for display. (Par 47, The results of the analysis may be used to optimize the Server 300, specifically, or the system 1, generally. Par 124, One or more monitors or display devices may also be connected to the system bus via an interface. In addition to display devices, computers may also include other peripheral output devices, which may be connected through an output peripheral interface. Par 113, the present invention is also a method and system for generating the scripts utilized by a load testing program to evaluate the performance of an application under a load. Thus, it’s obvious to display the results of the analysis and evaluation for performance test.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective
filing date of the claimed invention to add perform client-side load balancing to allocate resources to conduct the automated performance test; execute the automated performance test based on the invoked PTS, the one or more dynamic clusters, and the client-side load balancing generate a result of the executed automated performance test for display, as conceptually seen from the teaching of Massa, into that of Kaitha and Sirota because this modification can help improve performance testing by removing proxy bottlenecks and dynamically scaling while helping distribute traffic to the server instances and preventing a single server from being overloaded.
As per Claim 4, Kaitha further teaches of the system of claim 1, wherein to invoke the PTS, the one or more processors are further programmed to: identify the PTS to invoke based on an identification of the PTS specified by the performance test request. (Par 14, The system may use machine-learning to determine whether the test environment [PTS: performance test service], test data, and/or test script is to be reconfigured to optimize the performance test. Par 21, Environment engine 106 may set up test environment 120 to include the specified set of servers 122, computing clusters 124, and application 126, based on the retrieved configuration. For example, to set up the test environment, environment engine 106 provisions computing resources in a cloud computing environment. The computing resources include servers 122, computing clusters 124, and application 126. Par 25, Updating the configuration of the test environment may include changing the specified set of servers 122, computing clusters 124, and applications 126.)
As per Claim 11, Kaitha further teaches of the system of claim 1, wherein the performance test request is received via an performance test Application Programming Interface call. (Par 22, The tasks may include calls to the API, queries, calculations, and/or the like. A test script may instruct the software application to use the specified servers, computing clusters, or applications to execute the calls to the API, queries, or calculations. Execution of each test case may produce a result. The result may include a return value from the software application, time consumed by the software application while performing a task, memory utilized by the software application while performing a task, CPU power utilized by the software application while performing a task, and/or the like.)
Re Claim 12, it is the method claim, having similar limitations of claim 1. Thus, claim 12 is also rejected
under the similar rationale as cited in the rejection of claim 1.
Re Claim 14, it is the method claim, having similar limitations of claim 4. Thus, claim 14 is also rejected
under the similar rationale as cited in the rejection of claim 4.
Re Claim 20, it is the product claim, having similar limitations of claim 1. Thus, claim 20 is also rejected
under the similar rationale as cited in the rejection of claim 1.
8. Claims 2, 3, 9, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kaitha (US PGPub 20210049093), in view of Sirota (US PGPub 20150135185), in view of Massa (US PGPub 20160014238), and further in view of Gardner (US PGPub 20220300407).
As per Claim 2, none of Kaitha, Sirota and Massa specifically teaches, however Gardner teaches of the system of claim 1, wherein the one or more processors are further programmed to: access a baseline performance of the one or more dynamic clusters for the type of the automated performance test; and estimate a testing capacity for each of the one or more dynamic clusters to execute the automated performance test based on the baseline performance, wherein the automated performance test is executed based further on the testing capacity. (Claim 2, developing, by the one or more computers, a performance test for a server system based on the particular user action sequence; running, by the one or more computers, the performance test to obtain baseline performance data indicating performance of the server system in the performance test; based on the baseline performance data, generating, by the one or more computers, success criteria for the performance test; and after performing an additional run of the performance test for the server system, evaluating, by the one or more computers, performance of the server system in the additional run [testing capacity] of the performance test using the generated success criteria. Par 9, The management system can additionally or alternatively take corrective action to a performance decrease, such as instructing a change to settings of the server being monitored, allocating additional hardware resources to the server, starting another instance of a server environment to better manage traffic, and so on. Par 101-102, As another example, if the performance data meets both a first threshold and a second threshold, the management system 110 may determine that the deviation should be classified as an error and may send a higher priority notification to the administrator and may perform additional actions such as adjusting the configuration settings of the server system 130 shown in FIG. 1.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective
filing date of the claimed invention to add to access a baseline performance of the one or more dynamic clusters for the type of the automated performance test; and estimate a testing capacity for each of the one or more dynamic clusters to execute the automated performance test based on the baseline performance, wherein the automated performance test is executed based further on the testing capacity, as conceptually seen from the teaching of Gardner, into that of Kaitha, Sirota and Massa because this modification can help improve performance testing by removing proxy bottlenecks and dynamically scaling.
As per Claim 3, none of Kaitha, Sirota and Massa specifically teaches, however Gardner teaches of the system of claim 2, wherein the one or more processors are further programmed to: schedule a first dynamic cluster, from among the one or more dynamic clusters, to run on a first underlying virtual or physical machine; and schedule a second dynamic cluster, from among the one or more dynamic clusters, to run on a second underlying virtual or physical machine. (Par 8, To carry out the performance monitoring, the management server can schedule tasks to run continually on monitored servers. This can involve requesting a server to perform monitoring tasks periodically, for example, by sending requests at regular intervals such as every minute, every 5 minutes, every 15 minutes, etc. The management server may select a set of tasks to monitor, and then may use a headless browser to request a monitored server to initiate each of the selected tasks at each interval. In some implementations, the management server issues the request for each task one-by-one in sequence, so that the server responds to the current monitored task before the management server requests the next monitoring task be performed. The management server can repeat the same series of tasks multiple times, and in some cases may initiate another round of performing the monitoring tasks as soon as the current round of performing the monitoring tasks is finished. The set of tasks to be monitored can be adjusted or changed by the management server from time to time.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective
filing date of the claimed invention to add to schedule a first dynamic cluster, from among the one or more dynamic clusters, to run on a first underlying virtual or physical machine; and schedule a second dynamic cluster, from among the one or more dynamic clusters, to run on a second underlying virtual or physical machine, as conceptually seen from the teaching of Gardner, into that of Kaitha, Sirota and Massa because this modification can help improve performance testing by removing proxy bottlenecks and dynamically scaling.
As per Claim 9, none of Kaitha, Sirota and Massa specifically teaches, however Gardner teaches of the system of claim 1, wherein the one or more processors are further programmed to: access first data from a first target data management system (TDMS); access second data from a second TDMS; aggregate the first data and the second data; determine one or more service level indicates based on the aggregated first data and the second data; and determine whether one or more service level objectives have been met based on the one or more service level indicators. (Par 79-80, The management system 110 may determine a relative performance measure, such as a relative performance index (RPI), for the configuration settings of the server system 130. The RPI value indicates the level of performance when a particular combination of configuration settings is used, after the influence of the hardware resources and/or the load levels of a particular server environment have been removed or reduced. In order to remove the influences and determine the RPI, the management system 110 may normalize the performance results (e.g., the performance metrics calculated by the performance monitoring module 118 and/or the performance metrics stored in the data storage 120) for the hardware resources used by the server system 130 during the testing process, and/or normalize the load levels on the server system 130 during the testing process. In order to normalize the performance results and/or the load levels, the management system 110 may first obtain telemetry data about the functioning of the server system 130. The telemetry data may include an indication of which software modules are running on the server system 130, which hardware resources are allocated to the server system 130, load levels experienced by the server system 130 (e.g., total load including the traffic from the client devices), the current server configuration settings for the server system 130, etc. Par 81, Normalizing the performance results may involve scaling the performance results based on differences in load level and/or differences in hardware resources as indicated by the obtained telemetry data of the server system 130)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective
filing date of the claimed invention to add to access first data from a first target data management system (TDMS); access second data from a second TDMS; aggregate the first data and the second data; determine one or more service level indicates based on the aggregated first data and the second data; and determine whether one or more service level objectives have been met based on the one or more service level indicators, as conceptually seen from the teaching of Gardner, into that of Kaitha, Sirota and Massa because this modification can help improve performance testing by removing proxy bottlenecks and dynamically scaling.
Re Claim 13, it is the method claim, having similar limitations of claim 2. Thus, claim 13 is also rejected
under the similar rationale as cited in the rejection of claim 2.
Re Claim 19, it is the method claim, having similar limitations of claim 9. Thus, claim 19 is also rejected
under the similar rationale as cited in the rejection of claim 9.
9. Claims 5, 6, 7, 15, 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Kaitha (US PGPub 20210049093), in view of Sirota (US PGPub 20150135185), in view of Massa (US PGPub 20160014238), and further in view of Chouksey (US PGPub 20260149638).
As per Claim 5, none of Kaitha, Sirota and Massa specifically teaches, however Chouksey teaches of the system of claim 1, wherein the performance test request comprises one or more requirements for the automated performance test, and wherein to invoke the PTS, the one or more processors are further programmed to: determine, based on the one or more requirements, an intent of the performance test request without an express identification of the PTS to invoke; and identify the PTS to invoke based on the determined intent. (Par 22, The plurality of historic network configurations may be generated based on tested network performance requirements and data paths for a plurality of tested communication intents, that may be generated based on simulation and stored in the configuration database (104) before real-time deployment of the configuration database (104). As illustrated in FIG. 1, the configuration database (104) is communicatively coupled to the network configuration system (102) via the communication network (108). In another embodiment, the configuration database (104) may be integrated within the network configuration system (102).)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective
filing date of the claimed invention to add to determine, based on the one or more requirements, an intent of the performance test request without an express identification of the PTS to invoke; and identify the PTS to invoke based on the determined intent, as conceptually seen from the teaching of Chouksey, into that of Kaitha, Sirota and Massa because this modification can help improve performance testing by removing proxy bottlenecks and dynamically scaling.
As per Claim 6, Kaitha further teaches of the system of claim 5, wherein to determine the intent, the one or more processors are further programmed to: match the one or more requirements with a functionality of the type of automated performance test that is to be executed; and determine that the PTS provides the matched functionality, wherein the PTS is identified based on the determination. (Par 4, Performance testing may be an iterative process, requiring manual configuration of test data and environments to ultimately identify an environment [PTS: performance test service] that can execute the application in a manner that satisfies the performance requirement. PAr 15, In this regard, the system disclosed herein can spin up the test infrastructure when needed to accommodate testing requirements and is also capable of shutting down the infrastructure after the testing process completed to save the infrastructure cost. Par 32, The request may include the specified configuration of testing environment 200, test data, and a desired performance requirement. Testing environment 200 may include two servers, a computing cluster of three computing devices, and two data repositories.)
As per Claim 7, Kaitha further teaches of the system of claim 5, wherein the one or more processors are further programmed to: transmit, to a second PTS, based on the performance test request, a request to initiate the automated performance test; (Par 19, In an embodiment, test system 100 receives a request to execute a performance test on an application. Performance tests may determine the speed, responsiveness and stability of a computer, network, software program or device under a workload. Par 32, the testing engine 100 may receive a request to execute a performance test of an application using the configuration of testing environment 200.)
None of Kaitha, Sirota and Massa specifically teaches, however Chouksey teaches to determine, by the second PTS, that the PTS is to be invoked based on the intent; and invoke, by the second PTS, the PTS. (Par 22, The plurality of historic network configurations may be generated based on tested network performance requirements and data paths for a plurality of tested communication intents, that may be generated based on simulation and stored in the configuration database (104) before real-time deployment of the configuration database (104). As illustrated in FIG. 1, the configuration database (104) is communicatively coupled to the network configuration system (102) via the communication network (108). In another embodiment, the configuration database (104) may be integrated within the network configuration system (102).)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective
filing date of the claimed invention to add to determine, by the second PTS, that the PTS is to be invoked based on the intent; and invoke, by the second PTS, the PTS, as conceptually seen from the teaching of Chouksey, into that of Kaitha, Sirota and Massa because this modification can help improve performance testing by removing proxy bottlenecks and dynamically scaling.
Re Claim 15, it is the method claim, having similar limitations of claim 5. Thus, claim 15 is also rejected
under the similar rationale as cited in the rejection of claim 5.
Re Claim 16, it is the method claim, having similar limitations of claim 6. Thus, claim 16 is also rejected
under the similar rationale as cited in the rejection of claim 6.
Re Claim 17, it is the method claim, having similar limitations of claim 7. Thus, claim 17 is also rejected
under the similar rationale as cited in the rejection of claim 7.
10. Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kaitha (US PGPub 20210049093), in view of Sirota (US PGPub 20150135185), in view of Massa (US PGPub 20160014238), and further in view of Mohan (US PGPub 20120204150).
As per Claim 8, none of Kaitha, Sirota and Massa specifically teaches, however Mohan teaches of the system of claim 1, wherein to perform client-side load balancing, the one or more processors are further programmed to: identify a specific load distribution profile based on the type of the automated performance test, wherein the specific load distribution profile is based on real-world usage patterns. (Par 17, The scenarios may be analyzed to derive a number of metrics and reports useful for product development and/or "debugging." For example, the scenario analysis may include usage patterns indicative of a real-world usage frequency, usage time, method of use, and/or system performance of software and/or hardware components. Accordingly, areas of the system that are involved in heavy use may be prioritized to receive additional development effort and scrutiny. System developers and engineers may thus use the scenario analysis to improve the system under development. Further, scenario simulations may then be used to refine any changes to the system. Indeed, an iterative development may include using the captured scenario data to simulate the scenario in a new and/or revised system. The new and/or revised system may then be analyzed by using the embodiments disclosed herein so as to further refine the system, and so on.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective
filing date of the claimed invention to add to identify a specific load distribution profile based on the type of the automated performance test, wherein the specific load distribution profile is based on real-world usage patterns, as conceptually seen from the teaching of Mohan, into that of Kaitha, Sirota and Massa because this modification can help improve performance testing by removing proxy bottlenecks and dynamically scaling.
Re Claim 18, it is the method claim, having similar limitations of claim 8. Thus, claim 18 is also rejected
under the similar rationale as cited in the rejection of claim 8.
11. Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Kaitha (US PGPub 20210049093), in view of Sirota (US PGPub 20150135185), in view of Massa (US PGPub 20160014238), and further in view of Kritiansson (US PGPub 20180152534).
As per Claim 10, none of Kaitha, Sirota and Massa specifically teaches, however Kritiansson teaches of the system of claim 1, wherein the PTS comprises a microservice that instantiates each of the one or more dynamic clusters within a respective container in the containerized environment. (Par 49, By using the embodiments, it also becomes possible for a microservice container to deploy a new routing container on demand to dynamically create clusters, i.e. without relying on a central controller to setup the cluster. This feature is discussed more below. Par 62, The embodiments also allow microservices to dynamically set up clusters when needed, thus allowing the microservices themselves to re-configure the topology of the microservices infrastructure. For example, if a microservice determines that the load is too high it can clone itself and deploy a reverse proxy microservice to create and configure a cluster similar to a Kubernetes Pod, except that the cluster can dynamically be created in runtime. It also becomes possible to dynamically add more frontend servers (reverse proxy servers) in a plug-and-play fashion. In this case, new proxy servers can automatically configure themselves by reading configuration data store in the Bitverse network. Par 121, It could then configure and deploy a routing container and add more instances of itself to dynamically create a cluster.)
Therefore, it would have been obvious for one of the ordinary skill in the art before the effective
filing date of the claimed invention to add a microservice that instantiates each of the one or more dynamic clusters within a respective container in the containerized environment, as conceptually seen from the teaching of Kritiansson, into that of Kaitha, Sirota and Massa because this modification can help improve performance testing by removing proxy bottlenecks and dynamically scaling.
Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Darling (US Patent 7296268): Darling teaches of a system comprising: a control client that communicates with a load-balancing cluster of server nodes configured to service application-layer requests sent by user clients to a virtual address common to the cluster; a dynamic cluster-membership determiner configured to exoclusterly and dynamically determine, by the control client, which server nodes are members of the load-balancing cluster; The exocluster application-layer monitor can dynamically adjust so that it can monitor all of the members of the cluster as members are added and removed. At 310 of FIG. 3, the exemplary monitor/controller is instructed to monitor a given cluster. At 312, it dynamically determines the membership of the given cluster and the cluster state of each member of the cluster. It may do so via a "query" command. At 314, it exoclusterly monitors the members of the cluster from a client-perspective. In particular, it monitors the members of the cluster at the application-layer.
Jastrzebski (US PGPub 20170302730): Jastrzebski teaches that a system enabling the assignment of a DNS name to load balancers in a dynamically partitioned cluster environment may be provided, the system comprising a first level load balancer, a second level load balancer, a cluster configuration observer, and a plurality of servers, each configured to run one or more instances of applications, an instance of a first application being bound to a first port, the cluster configuration observer configured to receive cluster configuration information, the cluster configuration information comprising information indicative of one or more instances of running application and associated ports to which the one or more of instances is bound, and provide the cluster configuration information to a second level load balancer, the second level load balancer configured to receive configuration information of the second level load balancer that comprises the cluster configuration information, receive a request from the first level load balancer requiring a call to the first application, determine, based on the cluster configuration information, to which port the instance of the first application is bound, transmit the request to the port to which the instance of the first application is bound, and receive a response, the first level load balancer configured to receive the request from a client device, transmit, to the second level load balancer, the request, and receive the response from the second level load balancer, and transmit the response to the client device.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAE UK JEON whose telephone number is (571)270-3649. The examiner can normally be reached 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, Chat Do can be reached at 571-272-3721. 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.
/JAE U JEON/Primary Examiner, Art Unit 2193
Prosecution Insights