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 .
Response to Amendment
This office action is responsive to amendment filed on June 10, 2026. Claim 18 has been canceled. No claims have been added. Claims 1-17 presented for the examination and remain pending in the application.
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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3, 9, 11, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Intelligent Autoscaling of Microservices in the Cloud for Real-Time Applications (i.e., 1, 2021, accepted February 13, 2021, date of publication February 24, 2021, date of current version March 5, 2021). (i.e., note that the Examiner cited pages are from the actual pages from 35464-35476 of this NPL). ABEER ABDEL KHALEQ, (Member, IEEE) (i.e., Applicant provided NPL resource), (hereinafter ABEER) in view of Doshi et al. U.S. Pub. No. 2021/0117249 A1, (hereinafter Doshi) and further in view of Huizenga U.S. Pub. No. 2008/0034370 A1, (hereinafter Huizenga).
Regarding claim 1.
ABEER teaches a method for scaling microservices in a service mesh (note that here the term “workload and job (i.e., traffic)” have been interpreted in light of the specification on Page. 5, lines 17-22 in equal meanings and also the term “service mesh” refers to “traffic”. ABEER teaches in the [Abstract] developing a cloud application based on a microservice architecture imposes different challenges including scalability at the container level. What adds to the challenge is that cloud applications impose quality of service (QoS) requirements and have various resource demands requiring a customized scaling approach...), the method comprising:
obtaining information representing a workload of a microservice chain, wherein the workload comprises at least one job (ABEER teaches [On. Page. 35465 in the right column under the title “A. Microservices Autoscaling and QoS, lines 24-29] investigated the effect of absolute versus relative metrics in microservices autoscaling. They suggested that for CPU intensive workloads (i.e., note that the workload indicates a traffic which is the claimed at least one job), absolute metrics such as CPU utilization enable more accurate decisions than the relative metrics used by the default Kubernetes autoscaling algorithm and further ABEER teaches [On. Page. 35470 in the left column bellow Fig. 5 “Machine learning autoscaling modules” there are description of the loop steps from 1-7, lines 3-26] the microservice resource requirement determined and the system runs a vertical scaling on the microservice or pod to get the initial recommended settings for the microservice or pod CPU and memory request…, determine the resource usage consumption based on the information and a new pod will be identified for resource type scaling. Also, this step will help in vertical autoscaling to adjust the resource request if needed…(note that “microservice chain is not defined” is not defined in the claims. Under the broadest reasonable interpretation, ABEER’s microservices is a chain (see page 35468, figure 1.));
obtaining information representing current and historical resource allocations of the service mesh, determining a reward, wherein the reward is indicative of completed jobs and allocated resources of the service mesh (ABEER teaches [On. Page 35470 in the left column bellow Fig. 5 “Machine learning autoscaling modules” there are description of the loop steps from 1-7 in step 4, lines 9-16] run a query to identify the microservice or pod trend consumption of the ratio of consumed versus requested resources. This step can benefit from historical machine learning for an incoming pod based on its trend in resource usage a new pod will be identified for resource type scaling (i.e., note that here the term “new” indicates the “current” resource allocation and the historical machine learning for the trend usage resource indicates the historical resource allocation). Also, this step will help in vertical autoscaling to adjust the resource request if needed and further ABEER teaches [On. Page. 35470 in the right column below the “Input: Current Environment class (Env), current Agent Action (Act) after the end of number 28” in lines 5-11] the scaled pods are deployed,…The RL agent will receive a reward based on the current pods’ response time…);
running a reinforcement learning (RL) model on the information representing the workload, current and historical resource allocations, reward, and (ABEER teaches [On. Page 35470 in the left column bellow Fig. 5 “Machine learning autoscaling modules” in step 5, lines 19-37] run the HPA (i.e., Kubernetes auto-scaler) based on identified resource from step 4., and 6. Collect pods and HPA logs from Stack driver and run the horizontal RL (i.e., Reinforcement Learning) agent to identify threshold values for the maximum number of pods and resource utilization that will minimize response time. 7. Continue from step 1 as long as the pods are deployed. Here is the algorithm used in the step function of the RL (i.e., Reinforcement Learning) agent Environment: The algorithm represents the autoscaling environment where the RL agent (i.e., model) will get the observation to perform the need action… (i.e., note that here the RL agent (i.e., model) get the observation which indicates the model information representing the workload) and further teaches [On. Page. 35470 in the right column below the “Input: Current Environment class (Env), current Agent Action (Act) after the end of number 28” in lines 1-13] where new pods is the new number of pods to deploy for the autoscaling…The RL (i.e., Reinforcement Learning) agent will receive a reward based on the current pods’ response time aiming at maximizing the reward as long as the response time is less than or equal the QoS value…); and
obtaining a further resource allocation for the workload as an output of the RL model (ABEER teaches [On. Page 35470 in the left column bellow Fig. 5 “Machine learning autoscaling modules” in step 7, lines 25-35] the algorithm represents the autoscaling environment where the RL agent (i.e., RL model) will get the observation to perform the needed action…, and further ABEER teaches [On. Page. 35470 in the right column below the “Input: Current Environment class (Env), current Agent Action (Act) after the end of number 28” in lines 1-13] where new pods is the new number of pods to deploy for the autoscaling…The RL agent will receive a reward based on the current pods’ response time aiming at maximizing the reward as long as the response time is less than or equal the QoS value…).
While, ABEER teaches about the obtaining of information representing a workload of the microservices above, ABEER does not explicitly teach obtaining the microservice chain comprises a path of two or more microservices through the service mesh for performing the workload; producing a feedback signal, wherein the feedback signal is indicative of a delay for increasing the resource allocation of the service mesh, and running feedback signal.
However, Doshi teaches obtaining the microservice chain comprises a path of two or more microservices through the service mesh for performing the workload (Doshi teaches in Para. [0225] about the microservices elements or devices in a data path with proper keys can be avoided, but can be utilized An IPU can negotiate security with a device in a chain or path of devices. After security through a path of devices is accomplished, a data path to devices in the path can be trusted and Doshi further teaches in Para. [0177] for example, secure resource manager 1902 can run a service mesh to decide what resource is to execute workload);
producing a feedback signal, wherein the feedback signal is indicative of a delay for increasing the resource allocation of the service mesh (Doshi teaches in Para. [0316] telemetry, tracing, monitoring and logging and secure resource management can provide completion, status, logs, and events to its IPU (i.e., infrastructure processing unit) local control plane. At (14), local events, Logs, Status Changes can cause a feedback loop (i.e., producing a feedback signal) for dynamic adjustments to maintain Policies…, and Doshi teaches in Para. [0338] an example is for RPC offload, the IPU can timestamp each individual RPC session for latency/jitter (i.e., indicative of a delay) and associate errors and associated events. These can feed back into the IPU control plane for dynamic adjustments and further, Doshi teaches in Para. [0188] managing availability and scalability. Various embodiments of IPU's SDN 2006 can implement service management such as Service Mesh load balancing policies,... The IPU can also manage local resource allocations (i.e., the IPU here maintains and adjusts the mesh load balancing to manage (i.e., increase) the local resource allocation)); and
running feedback signal (Doshi teaches in Para. [0316] local events, Logs, Status Changes can cause a feedback loop (i.e., producing a feedback signal) for dynamic adjustments to maintain Policies).
Therefore, ABEER and Doshi are analogues arts, and they are in the same field of endeavor as they both are directed to the process of resource allocation and providing a feedback signal in a cloud system to provide a better services.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of causing a feedback loop for dynamic adjustment to maintain policies and indicate latency/jitter (i.e., delay) ([0316] and [0338]) as taught, by Doshi into ABEER invention. One would have been motivated to do so in order to the system improves total cost of ownership, reduce application and network latency, reduce network backhaul traffic and associated energy consumption, improve service capabilities, and improve compliance with security or data privacy requirements.
Further, ABEER in view of Doshi does not explicitly teach wherein the delay is based at least in part on a boot time for allocating and configuring the increased resources.
However, Huizenga teaches wherein the delay is based at least in part on a boot time for allocating and configuring the increased resources (Huizenga teaches in Para. [0006] delays in resource allocation may impact the performance and response times of the application making the request and further, Huizenga teaches in Para. [0038] that the initial policy might give the application a very large reserve resource allocation that allows the application to grow rapidly during initialization to expedite system start up. The workload management system 4 would then revert to a steady-state policy that limits the reserve resource allocation to a much smaller quantity).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of resource allocation delay and response time to allow the application to grow rapidly based on the allocation of resources ([0006] and [0038]) into the teachings of ABEER in view of Doshi invention. One would have been motivated to do so in order to improve an application workload management by avoiding resource sharing, thus sharing the data processing resource without penalizing applications, and providing an incremental increase in the guaranteed minimum resource allocation, and hence increasing the share of the resource, and effectively managing application work-loads in the data processing system using the notion of the dynamically maintainable reserve resource allocation of the data processing resource.
Regarding claim 3.
ABEER teaches wherein the current resource allocation of the service mesh and the workload of the microservice chain are represented by a state of the RL model (ABEER teaches [On. Page 35470 in the left column bellow Fig. 5 “Machine learning autoscaling modules” in step 7, lines 25-35] the algorithm represents the autoscaling environment where the RL agent (i.e., RL model) will get the observation to perform the needed action…,see page 35465, col. 1 where auto scale microservices in the
cloud based on their demands and QoS…auto scale the workload with minimum user interaction based on the workload log data (i.e., service mesh). (Note that “microservice chain is not defined” is not defined in the claims. Under the broadest reasonable interpretation, ABEER’s microservices is a chain (see page 35468, figure 1.)).
Regarding claims 9 and 17.
Claims 9 and 17 incorporate substantively all the limitation of claim 1 in a device, a computer program product and a computer readable storage form and are rejected under the same rationale. Furthermore, regarding the limitations of device and readable storage, the prior art of record Bahl teaches in Para. [0028], [0030] and [0126].
Regarding claim 11.
Claim 11 incorporates substantively all the limitation of claim 3 in a device form and is rejected under the same rationale. Furthermore, regarding the limitations of device and readable storage, the prior art of record Bahl teaches in Para. [0028] and [0030].
Claims 2 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over ABEER in view of Doshi further in view of Huizenga and further in view of HANSEL: Adaptive horizontal scaling of microservices using Bi-LSTM Ming et al. (i.e., Applicant provided NPL resource). Received in revised form 27 January 2021. Accepted 14 February 2021. Available online 5 March 2021, (hereinafter Ming).
Regarding claim 2. ABEER in view of Doshi further in view of Huizenga teaches the method according to claim 1.
ABEER in view of Doshi further in view of Huizenga does not explicitly teach wherein a resource allocation of the service mesh comprises a queue of jobs for at least one microservice and a number of instances for running the at least one microservice.
However, Ming teaches wherein a resource allocation of the service mesh comprises a queue of jobs for at least one microservice and a number of instances for running the at least one microservice (Ming teaches [On. Page. 5 under the title “5. Design of microservice elastic scaling and (5.1)”, lines 1-14] the elastic scaling…, the operation of elastic scaling consists of two parts: 10 executing…, 2) determining number of microservices…, there are two approach is to periodically monitor events (such as CPU, workloads, queues, and so on) and perform elastic operations on resources based on thresholds. The active approach is based on predicting workload ahead of time from past workloads
to scale horizontally (i.e., note that workloads, queues make up the service mesh)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of microservice elastic scaling to monitor resource, workload and queues ([On. Page. 5 under the title “5. Design of microservice elastic scaling and (5.1)”, lines 1-14]) as taught, by Ming into the teachings of ABEER in view of Doshi further in view of Huizenga invention. One would have been motivated to do so in order to monitor and determine the resource allocation and the workload in an efficient manner.
Regarding claim 10.
Claim 10 incorporates substantively all the limitation of claim 2 in a device form and is rejected under the same rationale. Furthermore, regarding the limitations of device and readable storage, the prior art of record Bahl teaches in Para. [0028] and [0030].
Claims 4, 5,12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over ABEER in view of Doshi further in view of Huizenga and further in view of Di Balsamo et al. U.S. Pub. No. 2015/0277987 A1, (hereinafter Di).
Regarding claim 4. ABEER in view of Doshi further in view of Huizenga teaches the method according to claim 1.
ABEER in view of Doshi further in view of Huizenga does not explicitly teach wherein a job is processed by at least one microservice and has an associated deadline.
However, Di teaches wherein a job is processed by at least one microservice and has an associated deadline (Di teaches in Para. [0057] resource provisioning provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment in SLA (i.e., not that here providing a resource in a cloud computing environment is the claimed “at least one microservice)…, and further Di teaches in Para. [0060] the workload (i.e., job) plan 403 may include job information including job start time and job deadlines).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of providing computing resources and a workload plan and starting and a job completing ([0057] and [0060]) as taught, by Di into the teachings of ABEER in view of Doshi further in view of Huizenga invention. One would have been motivated to do so in order to the resource pool is modified to bring a resource pool parameter within a resource range in response to determining that the job forecast exceeds a job deadline which ensures that the efficiency of a job scheduling system is increased effectively.
Regarding claim 5.
Di further teaches wherein the reward is assigned if the job is completed before the associated deadline (Di teaches in Para. [0087] the job deadline may be a time limit for one or more jobs to be completed (i.e., a reward which indicates a function of a completion time). As described above, the job deadline may be information contained in the workload plan..., then the one or more jobs represented by the job forecast may not be completed before the job deadline with additional resources the one or more jobs may be completed earlier and may result in a job completion date prior to the job deadline (i.e., before the associated deadline)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of equally divide the allocation schedule into time slots of equal size and using one or more jobs may be completed earlier and may result in a job completion date prior to the job deadline ([0060] and [0087]) as taught, by Di into the teachings of ABEER in view of Doshi further in view of Huizenga invention. One would have been motivated to do so in order to prevent the job forecast from exceeding the job deadline more resources may be allocated to the resource pool in an efficient manner (Di. [0087]).
Regarding claim 12.
Claim 12 incorporates substantively all the limitation of claim 4 in a device form and is rejected under the same rationale. Furthermore, regarding the limitations of device and readable storage, the prior art of record Bahl teaches in Para. [0028] and [0030].
Regarding claim 13.
Claim 13 incorporates substantively all the limitation of claim 5 in a device form and is rejected under the same rationale. Furthermore, regarding the limitations of device and readable storage, the prior art of record Bahl teaches in Para. [0028] and [0030].
Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over ABEER in view of Doshi further in view of Huizenga further in view of Di and further in view of Nagpal et al. U.S. Pat. No. 10,089,144 B1, (hereinafter Nagpal the first).
Regarding claim 6. ABEER in view of Doshi further in view of Huizenga further in view of Di teaches the method of claim 4.
ABEER in view of Doshi further in view of Huizenga further in view of Di does not explicitly teach wherein the reward is a function of a completion time of the job and the associated deadline.
However, Nagpal the first teaches wherein the reward is a function of a completion time of the job and the associated deadline (Nagpal the first teaches in [Col. 11, lines 51-67 and Col. 12, lines 1-9] as shown in FIG. 4 includes a technique to perform likelihood calculations 406 over an arbitrary number of resource dimensions (e.g., CPU units, network I/O, storage space, etc.)... A set of static scheduling operations (step 408) use a job specification database 412 to retrieve a time-to-finish value for each job (finish deadline time 410) to perform a static schedule of the particular job at hand for each resource dimension. Jobs that have a calculated relatively lower probability to complete by their respective assigned finish deadline times are assigned a respective weighting factor that is given in relationship to the calculated relatively lower probability. Such a weighting factor assigned to a job serves to influence the reward value that is calculated (i.e., reward function) in subsequent steps. Specifically, and as shown, when all of the then-current jobs have been statically scheduled (step 408), and all of the then-current jobs have been assigned a weight that is commensurate to a probability to finish by respective finish deadline times (step 414), then the set of jobs can be rescheduled such that highest reward jobs (reward calculation step 418 that calculates reward values based on the increased weights) are scheduled first (e.g., in a greedy fashion) over the set of then-current resources (step 420)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of providing a set of static scheduling operations (step 408) use a job specification database 412 to retrieve a time-to-finish value for each job (finish deadline time 410) to perform a static schedule of the particular job at hand for each resource dimension assigned to a job serves to influence the reward value that is calculated (i.e., reward function) in subsequent steps ([Col. 11, lines 51-67 and Col. 12, lines 1-9]) as taught, by Negpal the first into ABEER in view of Doshi further in view of Huizenga further in view of Di invention. One would have been motivated to do so since this method enables avoiding overloading a computing system with administrative tasks, thus avoiding situations where users might experience effects of an overloaded system. The method enables prioritizing jobs might need such that performance objectives are optimized to achieve service level agreement (SLA) parameters.
Regarding claim 14.
Claim 14 incorporates substantively all the limitation of claim 6 in a device form and is rejected under the same rationale. Furthermore, regarding the limitations of device and readable storage, the prior art of record Bahl teaches in Para. [0028] and [0030].
Claims 7, 8, 15 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over ABEER in view of Doshi further in view of Huizenga and further in view of Nagpal et al. U.S. Pub. No. 2018/0136958 A1, (hereinafter Nagpal).
Regarding claim 7. ABEER in view of Doshi further in view of Huizenga teaches the method according to claim 1.
ABEER in view of Doshi further in view of Huizenga does not explicitly teach wherein information representing historical resource allocation is collected for a period of time.
However, Nagpal teaches wherein information representing historical resource allocation is collected for a period of time (Nagpal teaches in Para. [0025] based on historical resource usage data collected over time and/or a prediction of resources to be available at some time in the future, the assessment of past resource usage may be based on a designated period of time, e.g., the past day, week, month, or year).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of collecting historical a predicted resources in a period of time ([0025]) as taught, by Nagpal into the teachings of ABEER in view of Doshi invention. One would have been motivated to do so in order to the storage resources of the various physical host machines are virtualized into one global logically-combined storage pool that is high in reliability, availability, and performance. The significant performance advantages can be gained by allowing the virtualization system to access and utilize local storage. The degradation of the performance can be minimized.
Regarding claim 8. ABEER in view of Doshi teaches the method according to claim 1.
ABEER in view of Doshi wherein the period of time is a function of an estimated value of the delay for allocating resources.
However, Nagpal teaches wherein the period of time is a function of an estimated value of the delay for allocating resources (Nagpal teaches in Para. [0032] the host machine's predicted actual or predicted (i.e., estimated) response time may also include the time delay in sending or receiving data over network 140 if the storage device utilized by the host machine is connected to the host machine over network 140 (e.g., cloud storage 126 or networked storage 128) and further, teaches in Para. [0046] based on historical resource usage data collected over time and/or a prediction of resources to be available at some time in the future. The available resources may represent resources available at a point in time or a prediction of available resources at some time in the future).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of predicting response time to include a delay based on historical resource usage ([0032] and [0046]) as taught, by Nagpal into the teachings of ABEER in view of Doshi further in view of Huizenga invention. One would have been motivated to do so in order to contemplate any suitable manner of determining available resources of host machines.
Regarding claim 15.
Claim 15 incorporates substantively all the limitation of claim 7 in a device form and is rejected under the same rationale. Furthermore, regarding the limitations of device and readable storage, the prior art of record Bahl teaches in Para. [0028] and [0030].
Regarding claim 16.
Claim 16 incorporates substantively all the limitation of claim 8 in a device form and is rejected under the same rationale. Furthermore, regarding the limitations of device and readable storage, the prior art of record Bahl teaches in Para. [0028] and [0030].
Response to Arguments
Section 103 rejection
Applicant argues that the proposed Abeer-Doshi-Huizenga combination fails to disclose, teach or suggest "wherein the feedback signal is indicative of a delay for increasing the resource allocation of the service mesh, wherein the delay is based at least in part on a boot time for allocating and configuring the increased resources," (Remarks, page 8).
In response to the above argument, the Examiner respectfully disagrees because the above indicted limitation was part of the amended portion of the limitation that thought expressly by the prior art of record Huizenga. For example, Huizenga discloses in para. [0006] how the resource allocation can be made and the disadvantage of the resource sharing approach is that an application may be initially given a smaller guarantee of a resource than it actually needs during periods of peak resource usage…, if the resource is memory, the application would suffer latency while data is flushed to disk and memory is freed or otherwise reclaimed. Such delays in resource allocation may impact the performance and response times of the application making the request (i.e., a delay for increasing the resource allocation of the request (the service)). Further, as indicated above in para. [0006] about the peak resource usage, further in para. [0038] indicated that the resource allocation applied at predetermined times during a twenty-four hour cycle when peak resource usage is anticipated, such as twice per day from 9:00 a.m. to 10:00 a.m. and from 1:00 p.m. to 5:00 p.m. Note that the size of the reserve resource allocation may change depending on when it is assigned. For example, an exemplary synchronous time quanta approach might be to use an initial reserve policy for an application following application start up (e.g., starting twenty minutes after system boot) followed by reversion to a steady-state reserve policy as the application enters a steady-state mode. Therefore, the above argument is not persuasive.
Applicant also argues by reproducing the cited paragraphs of Doshi to indicates that these all cited paragraphs for example, para. [0188] and para. [0316] do not disclose that the SDN controller is able to determine a delay for increasing the resource allocation of the service mesh, as claimed. Further, the Applicant arguers that Doshi discloses a general IPU framework for the IPU local control plane that may receive completion, status, logs and events from telemetry, tracing, monitoring/logging and resource management functions. There is no disclosure in paragraph 0316 of Doshi, however, that the status received from the general telemetry, tracing, monitoring/logging and resource management functions are tied to the service mesh feature, and thus no disclosure that the general telemetry, tracing, monitoring/logging and resource management functions determine a delay for increasing the resource allocation of the service mesh, as claimed. (Remarks, pages 9-10).
In response to the above argument, the Examiner respectfully disagrees. First, the claimed limitation does not include the “telemetry, tracing, monitoring/logging” to determine a delay for increasing the resource allocation of the service mesh. Second, the Examiner still believed that the prior art of record Doshi expressly teach in para. [0309]-[0111] The IPU can also manage local resource allocations (i.e., the IPU here maintains and adjusts the mesh load balancing to manage (i.e., increase) the local resource allocation)), and further, Service Quality Objectives parameters can include one or more of Telemetry, Latency, Jitter, Logging, Monitoring, Priority. SQO Actions can include one or more of: Resource allocations, Bandwidth, QoS, Scheduling, Monitor and Logging actions. Service Quality Objectives (SQO) can include items such as telemetry, logging, monitoring, responses and end-to-end latency/jitter, etc. Doshi discloses in para. [0263] FIG. 23B depicts an example manner by which an IPU can coordinate use of various resources. At 2350, an IPU can capture various security and resiliency related events or performance extrema events from any XPU…, and upon filtering the PMU telemetry, software may detect an abnormal number of unexpected events (e.g., orders of magnitude increases in machine check errors, floating point underflow events, etc.). Therefore, the above argument is not persuasive.
Furthermore, the Applicant indicates that neither Doshi nor Huizenga, either alone or in combination, disclose "wherein the feedback signal is indicative of a delay for increasing the resource allocation of the service mesh, wherein the delay is based at least in part on a boot time for allocating and configuring the increased resources," as recited in independent claim 1. Thus, the proposed Abeer-Doshi- Huizenga combination fails to disclose, teach or suggest every element of claim 1. Therefore, claim 1 and each of its dependent claims are in condition for allowance. For analogous reasons, Applicant further contends that claims 9 and 17, and any claims dependent therefrom, are in condition for allowance.
In response to the above argument, the Examiner respectfully disagree because the prior arts of record are still believed to teach all the limitations of independent claims 1, 9 and 17 under broadest reasonable claim interpretation.
Examiner note: The Examiner called the Applicant’s Attorney (i.e., Stanton A. Lewis) to discuss about a potential Examiner amendment to advance the prosecution. However, the Examiner attempted calls were not successful although, the Examiner left a voice mail at 214-953-6882.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BERHANU SHITAYEWOLDETSADIK whose telephone number is (571)270-7142. The examiner can normally be reached M-F.
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, Emmanuel Moise can be reached at 5712723865. 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.
/BERHANU SHITAYEWOLDETSADIK/Primary Examiner, Art Unit 2455
Prosecution Insights