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 .
Status of Claims
1. Claims 1-2, 8-9, and 15-16 are currently amended.
Claims 3 and 10 are cancelled.
Claims 20-22 are newly added.
Claims 1-2, 4-9, and 11-22 are pending.
Claims 1-2, 4-9, and 11-22 are rejected.
Continued Examination Under 37 CFR 1.114
2. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on January 21, 2026 has been entered.
Response to Arguments
3. Regarding Prior Art Rejections:
Applicant's arguments filed January 21, 2026 have been fully considered but they are not persuasive. The rejections under 35 U.S.C. 103 are maintained. Additionally, applicant’s arguments are rejected under a new ground of rejection necessitated by the amendment.
4. Applicant argues in remarks:
Without conceding to the propriety of the rejection and to advance prosecution, the independent claims have been amended largely as discussed in the aforementioned interview. In particular, independent claims 1, 8, and 15 have been amended to recite (emphasis added):
"report[ing], using a monitoring framework, to a performance monitoring
observer at a configurable fixed interval, characteristics including input characteristics
of the request queue, output characteristics, payload compression characteristics of
the cloud storage gateway microservice, and processing utilization resource usage
characteristics ... related to the processing of the request and the storing or retrieving
of the data."
Neither Chopra nor Aronovich teaches or suggests a configurable fixed interval for reporting processing characteristics. The Office cites Chopra for teaching reporting processing characteristics to a performance monitoring observer according to a configurable reporting interval. The Office suggests that the storage rate in Chopra is analogous to the reporting interval. Office Action, Page 6. But the storage rate is not an interval for reporting performance monitoring data to a performance monitoring entity. The storage rate is independent of any reporting to a performance monitoring entity such as the performance monitoring observer now claimed.
Applicant's amended, independent claims also recite the reporting of multiple types of characteristics: input characteristics of the request queue, output characteristics, payload compression characteristics of the cloud storage gateway microservice, and processing utilization resource usage characteristics. The Office draws an analogy to Applicant's performance characteristics and Chopra's resource usage data, but Chopra does not teach or suggest these various types of characteristics.
The Office cites Aronovich for teaching relative to the use of "diagonal scaling," which combines vertical and horizontal scaling. Aronovich, like Chopra, does not teach or suggest reporting processing characteristics to a performance monitoring observer according to a configurable reporting interval, or reporting various types of processing characteristics to be used in decisioning regarding horizontal and vertical scaling.
Applicant's independent claims, as amended, are patentable over Chopra and Aronovich for at least the above reasons. Dependent claims 2, 9, and 16 are amended herein only for consistency with amended base claims. Dependent claims 2, 4, 7, 9, 13, 14, 16, and 19 incorporate the above-discussed recitations and so are patentable over Chopra and Aronovich for at least the same reasons just discussed.
With regard to dependent claims 5, 6, 11, 12, 17, and 18, the Office cites Chang for its general discussion of encryption and compression in a cloud storage system. Chang does not discuss horizonal and vertical autoscaling, or any of the specifics discussed above with respect to Applicant's independent claims. Dependent claims 5, 6, 11, 12, 17, and 18 are patentable over Chopra, Aronovich, and Chang for at least the same reasons already discussed with respect to Chopra and Aronovich as applied by the Office to Applicant's independent claims.
New dependent claims 20-22 have been added herein to define additional embodiments. These claims recite that the performance monitoring observer is configured to transmit scaling decisions to both the horizontal and vertical scalers while coordinating between them to avoid scaling interference. See Applicant's specification, paragraph [0036]. These claims incorporate the recitations discussed above with respect to the independent claims. The cited references do not teach or suggest such a combination of features.
As explained above, claims 1, 2, 4-9, and 11-22 are not obvious in view of the art cited by the Office. Withdrawal of the rejections under Section 103 and allowance of all claims is respectfully requested.
5. Examiner respectfully disagrees with applicant. Chopra does teach of “a configurable fixed interval for reporting processing characteristics.” Chopra teaches the trigger condition is a change in the rate of data storage in the data management device by a client during a predetermined period of time when compared to the rate of data storage in the data management device by the client during a prior predetermined period of time. In one or more embodiments of the invention, the trigger condition is the amount of change, e.g., a ratio, a percentage, a fixed quantity, etc., of the rate of data storage in the data management device by the client in a first time period when compared to the rate of data storage in the data management device by the client in a second time period (Col. 9, lines 16-27). The predetermined period of time by the client is analogous with a configurable fixed interval for reporting the processing characteristics. The cloud storage gateway monitor monitors the storage of client data over a predetermined period of time. Additionally, Applicant has amended the claims to include the specific processing characteristics including:
input characteristics of the request queue,
output characteristics of the system,
payload compression characteristics of the cloud storage gateway microservice, and
processing utilization resource usage characteristics of the system related to the processing of the request and the storing or retrieving of the data.
Chopra teaches of a rules engine that may match the client data storage histories obtained by the cloud storage gateway monitor (121) to one or more rules (124). The rules may specify operational characteristics of the cloud storage gateway(s) (130, FIG. 1A) when the client data storage histories meet a trigger requirement of the rule (Col. 8, lines 65 – Col. 9, lines 3). Moreover, these rules include (Col. 9, lines 38-44):
(i) an amount of a buffer of the cloud storage gateway assigned to the client,
(ii) synchronous or asynchronous storage of data in the buffer and a cloud storage,
(iii) purging of the buffer,
(iv) sending of an alert,
(v) storing data to a data storage of the cloud storage gateway via file shares or block shares, and/or
(vi) implementing thin provisioning of the client data.
These rules can be mapped to the reporting characteristics of the presently claimed invention in the following way:
(i) an amount of a buffer of the cloud storage gateway assigned to the client [Wingdings font/0xE0] input characteristics of the request queue,
The size of the buffer should be assigned to clients based on their input throughput requirements. This is further supported by Chopra, Col. 11, lines 4-11, The persistent storage (132) may host a buffer (132A) that temporarily stores data received from the clients. The storage capacity of the buffer (132) may be allocated on a per client basis. In other words, portions of the storage capacity of the buffer (132) may be allocated to each client storing data in the data management device. The storage capacity of the buffer (132) may be allocated by the storage manager (132).
(iii) purging of the buffer [Wingdings font/0xE0] processing utilization resource usage characteristics of the system related to the processing of the request and the storing or retrieving of the data,
A buffer is purged when it is full or reaches a usage threshold. This relates to the utilization of storage resources.
(iv) sending of an alert, [Wingdings font/0xE0] output characteristics of the system,
This is further supported by Chopra, Col. 9, lines 59-67, Utilizing the rules matched by the rule engine (122), the cloud storage gateway manager (123) generates modification messages based on the operational characteristics specified by the matched rules. After the generation, the modification messages are sent to the cloud storage gateways. The modification messages may be based on the operational characteristics specified by the one or more matched rules and may include one or more modification of the operational characteristics of the cloud storage gateways.
(v) storing data to a data storage of the cloud storage gateway via file shares or block shares [Wingdings font/0xE0] payload compression characteristics of the cloud storage gateway microservice, and/or
Block shares require different optimization and compression than file shares. This is further supported by Chopra, Col. 11, lines 31-35, Utilizing block shares, rather than file shares, may reduce the computing resources required to obtain the client data from the data storage (132B) when compared to obtaining the data using file shares at the cost of retrieving some data is not a part of the requested client data.
Moreover, Chopra teaches of a scaling decision by monitoring trends associated with the clients and modify the computing resources allocated to fulfill the client’s data storage/access requests and/or the method in which the storage/access are performed (Col. 5, lines 18-23). However, Chopra does not explicitly teach that the scaling decision is transmitted to either a vertical or horizontal scaler. However, in analogous art, Aronovich teaches:
[0072] The general approach of diagonal scaling is to scale application instances vertically (allocating or de-allocating resources), and when an application instance or a host are saturated, or when an application instance is idle, to then scale horizontally (create or remove application instances). Subsequent to scaling horizontally, continue to scale application instances vertically; [0074] The method 500 begins (step 502) with applying vertical scaling operations for an application instance (step 504). That is, resources are either allocated or de-allocated to/from the application instance to satisfy the resource requirements necessitated by the application instance. When the application instance is either saturated (fully utilized) or idle, or when a host is saturated, the method 500 may apply horizontal scaling operations for the application instance (step 506). To wit, upon performing the vertical scaling of allocating or de-allocating resources in step 504, and determining that the application instance is still either fully saturated or idle, the application instance is then horizontally scaled by either adding or removing application instances thereof. Following the horizontal scaling operations (step 506), the method returns to applying (and continuing to apply thereinafter) vertical scaling operations if necessary (step 504); [0075] FIG. 6 illustrates an additional flowchart diagram depicting a method 600 for automatic diagonal scaling of workloads in a distributed computing environment, in accordance with aspects of the present invention. The method 600 begins by automatically tracking the resource consumption of each of one or more application instances and compares the consumption of each of the application instances to the resource allocation of the application instance (step 602). The method 600 then continues by computing modification operations (increases or decreases) of resource allocations to the application instances (step 604), in accordance with the results of the comparison in step 602. Next, the computed modification operations are refined according to priorities of the applications and/or application instances, and available resources (step 606). The computed modification operations are then dynamically applied to the application instances respectively (step 608), where the modification operations are of various types, illustrated in steps 610 and 612.).
6. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chopra with the teachings of Aronovich to transmit the scaling decision to at least one of a vertical scaler or a horizontal scaler to perform a scaling action on the cloud storage gateway microservice, the storage backend microservice, or both based on the scaling decision, wherein the vertical scaler is configured to determine resources available for an instance of the cloud storage gateway microservice and the horizontal scaler is configured to determine a number of instances of the cloud storage gateway microservice. By dynamically being able to scale resources/instances either vertically or horizontally, actual resource consumption of application instances is automatically tracked and compared to allocated resources of the application instances. Second, the allocated resources and the resource limits thereof are automatically tuned (increased/decreased) according to the compared consumption to allocation of these resources. More particularly, when an application's workload grows, the mechanisms described herein make additional resources available to the application. Similarly, when the workload is reduced, the resources are decreased. Third, vertical and horizontal scaling are used automatically, according to application instance and/or host status and policies. Fourth and lastly, the functionality herein is customizable, efficient, and easy to configure. For example, items that can be set by users may include: maximum bounds on consumption of different resources (e.g., based on historical statistics and cost constraints); minimal bounds on availability of different resources; triggers for determining that a scaling operation is required; and policies for integrating the vertical and horizontal scaling, as discussed in Aronovich ([0030]). This ensures that resource utilization and allocation is done in the most efficient way, ensuring the cloud storage service always has the appropriate number of resources to function.
Therefore, together, Chopra and Aronovich teach of a cloud storage gateway microservice that reports to an observer, in a fixed interval, input, output, and resource usage metrics related to the processing of the request and storing or retrieving data. A scaling decision is determined and transmitted to either a vertical or horizontal scaler.
7. Additionally, applicant argues that Chang does not discuss horizontal and vertical autoscaling or any of the specifics discussed above with respect to Applicant’s independent claims. However, Examiner respectfully disagrees. Chang teaches of a cloud storage gateway that provides secure storage services in a cloud environment (Abstract). This is analogous with the cloud storage gateway described in Applicant’s independent claims. Chopra teaches of a cloud storage gateway and makes a scaling decision based on monitoring of input characteristics during a fixed interval. Similarly, Aronovich teaches of dynamically using vertical and horizontal scaling in a cloud computing environment. Lastly, Chang teaches of secure storage services in a cloud storage gateway. This helps facilitate secure migration of data between the enterprise storage and the cloud storage can include providing a secure tunnel between the virtual machine and the cloud storage gateway in the cloud, as discussed in Chang ([0014]). By providing this extra security, user data is protected from malicious attacks. Therefore, it would be reasonable to combine Chopra, Aronovich, and Chang to cover the limitations presented in the claims.
Lastly, Aronovich teaches the limitations of the newly added claims. Additionally, claims 2, 4-7, 9, 11-14, and 16-22 depend from and further limit amended claims 1, 8, and 15 and are therefore also rejected under 35 U.S.C 103. The full rejection can be found in the 35 U.S.C. 103 section below.
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.
8. Claims 1-2, 4, 7-9, 13-16, and 19-22 are rejected under 35 U.S.C. 103 as being unpatentable over Chopra et al. US 10635334 B1 in view of Aronovich US 20190158424 A1.
Chopra et al. US 10635334 B1; Aronovich US 20190158424 A1; and Chang et al. US 20140366155 A1 were cited in Notice of References Cited PTO-892 (Paper Number 20251016).
9. With regard to claim 1, Chopra teaches:
A system comprising:
a memory (Col. 3, lines 26-29, Transitory storage may be provided by, for example, random access memory. Persistent storage memory may be provided by, for example, a solid state hard disk drive.); and
at least one processing device configured to (Col. 3, lines 40-49; Examiner’s Note: Client devices are computing devices that contain processors to execute instructions.):
receive a request at a request queue of a cloud storage gateway microservice (Col. 6, lines 21-26, The storage node (120) may receive client data storage and/or access requests from the clients (100). In response to these requests, the storage node (120) may direct the cloud storage gateway(s) (130) to store or provide client data specified by the requests. The storage node (120) may direct the cloud storage gateway(s) (130) to store or provide client data specified by the requests based on one or more of the following factors: (i) presence or lack of previously stored client data in a particular cloud storage gateway, (ii) a utilization rate of computing resources of a particular cloud gateway, (iii) a type of data specified by the storage/access request, and (iv) an owner of the client that issued the data storage/access request. The storage node (120) may direct the cloud storage gateway(s) (130) to store or provide client data specified by the requests based on additional, fewer, and/or different factors without departing from the invention; Examiner’s Note: Requests can be received by the cloud storage gateways (storage gateway microservice).);
process the request at the cloud storage gateway microservice (Col. 5, lines 5-13, The storage node (120) may direct the cloud storage gateway(s) (130) to store or provide client data specified by the requests based on one or more of the following factors: (i) presence or lack of previously stored client data in a particular cloud storage gateway, (ii) a utilization rate of computing resources of a particular cloud gateway, (iii) a type of data specified by the storage/access request, and (iv) an owner of the client that issued the data storage/access request; Examiner’s Note: The storage node can direct the cloud storage gateway (storage gateway microservice) to store or provide client specified by the requests, which is analogous with processing the request.);
store or retrieve data related to the processed request using a storage backend microservice (Col. 6, lines 27-37, The storage node (120) may direct the cloud storage gateway(s) (130) to store or provide client data specified by the requests based on additional, fewer, and/or different factors without departing from the invention; Examiner’s Note: The cloud storage gateway (storage gateway microservice) can store or provide client specified by the requests, which is analogous with processing the request.); and
report, using a monitoring framework, to [[an]] a performance monitoring observer, [[in]] at a configurable fixed interval, characteristics including input characteristics of the request queue, output characteristics of the system, payload compression characteristics of the cloud storage gateway microservice, and processing utilization resource usage characteristics of the system related to the processing of the request and the storing or retrieving of the data, wherein the performance monitoring observer is configured to (Col. 8, lines 22-35, As discussed above, the storage node may receive client data storage/access requests from the client(s) (100, FIG. 1A) and modify the computing resources allocated to each of the clients for processing of data storage/access requests. To facilitate these functions, the example storage node (120) may include a cloud storage gateway monitor (121) that monitors the storage of client data over time, a rule engine (122) that specifies methods of operating the cloud storage gateway(s) (130, FIG. 1A) based on applying rules (124) to the storage of client data over time monitored by the cloud storage gateway monitor (121), and a cloud storage gateway manager (123) that generates and sends update messages to the cloud storage gateway(s) (130, FIG. 1) in response to the rule engine (122); Col. 8, lines 65 – Col. 9, lines 6, The rule engine (122) may match the client data storage histories obtained by the cloud storage gateway monitor (121) to one or more rules (124). The rules may specify operational characteristics of the cloud storage gateway(s) (130, FIG. 1A) when the client data storage histories meet a trigger requirement of the rule. When matched to a rule, i.e., meeting a trigger requirement of a rule, the matched rule may be provided to the cloud storage gateway manager (123); Col. 9, lines 7-27, In one or more embodiments of the invention, the rules (124) may be a data structure that specifies: (i) a trigger condition and (ii) one or more operational characteristics. In other words, the rules may specify the behavior of a cloud storage gateway based on the client data storage history associated with a client. In one or more embodiments of the invention, the client data storage history of multiple clients may be aggregated and the rules may trigger based on the aggregated histories. In one or more embodiments of the invention, the trigger condition is a change in the rate of data storage in the data management device by a client during a predetermined period of time when compared to the rate of data storage in the data management device by the client during a prior predetermined period of time. In one or more embodiments of the invention, the trigger condition is the amount of change, e.g., a ratio, a percentage, a fixed quantity, etc., of the rate of data storage in the data management device by the client in a first time period when compared to the rate of data storage in the data management device by the client in a second time period; Examiner’s Note: The cloud storage gateway monitor monitors one or more rules and determines if a trigger condition occurs during a predetermined period of time (configurable fixed interval). The rules include:
(i) an amount of a buffer of the cloud storage gateway assigned to the client [Wingdings font/0xE0] input characteristics of the request queue,
(iii) purging of the buffer [Wingdings font/0xE0] processing utilization resource usage characteristics of the system related to the processing of the request and the storing or retrieving of the data,
(iv) sending of an alert[Wingdings font/0xE0] output characteristics of the system,
(v) storing data to a data storage of the cloud storage gateway via file shares or block shares [Wingdings font/0xE0] payload compression characteristics of the cloud storage gateway microservice, and/or):
determine a scaling decision based on the characteristics (Col. 5, lines 18-41, Additionally, the storage node (120) may monitor data storage trends associated with the client(s) (100). Based on the monitoring, the storage node (120) may modify the computing resources allocated to fulfill the client data storage/access requests and/or the method in which the storage/access are performed. As used herein, modifying the computing resources allocated to fulfill the client data storage/access requests and/or the method in which the storage/access are performed may be referred to as a modification of a transfer characteristic of the data management device. The storage node (120) may modify the computing resources allocated to each of the clients and/or the method in which the storage/access are performed to maintain a quality of storage service to the clients. The quality of storage service may be, for example, a rate at which client data is stored, a maximum period of time before data sent to the data management device (150) for storage is available to be read, and/or a rate at which client data is provided to client(s). In another example, the quality of storage service may be a maximum amount of time before client data stored in the data management device is available to be retrieved. The storage node (120) may modify the aforementioned allocation of computing resources by sending a message to the cloud storage gateway(s) (130) specifying the modifications.); and
Chopra however, fails to explicitly teach to transmit the scaling decision to at least one of a vertical scaler or a horizontal scaler to perform a scaling action on the cloud storage gateway microservice, the storage backend microservice, or both based on the scaling decision, wherein the vertical scaler is configured to determine resources available for an instance of the cloud storage gateway microservice and the horizontal scaler is configured to determine a number of instances of the cloud storage gateway microservice
However, in analogous art, Aronovich teaches:
transmit the scaling decision to at least one of a vertical scaler or a horizontal scaler to perform a scaling action on the cloud storage gateway microservice, the storage backend microservice, or both based on the scaling decision, wherein the vertical scaler is configured to determine resources available for an instance of the cloud storage gateway microservice and the horizontal scaler is configured to determine a number of instances of the cloud storage gateway microservice ([0072] The general approach of diagonal scaling is to scale application instances vertically (allocating or de-allocating resources), and when an application instance or a host are saturated, or when an application instance is idle, to then scale horizontally (create or remove application instances). Subsequent to scaling horizontally, continue to scale application instances vertically; [0074] The method 500 begins (step 502) with applying vertical scaling operations for an application instance (step 504). That is, resources are either allocated or de-allocated to/from the application instance to satisfy the resource requirements necessitated by the application instance. When the application instance is either saturated (fully utilized) or idle, or when a host is saturated, the method 500 may apply horizontal scaling operations for the application instance (step 506). To wit, upon performing the vertical scaling of allocating or de-allocating resources in step 504, and determining that the application instance is still either fully saturated or idle, the application instance is then horizontally scaled by either adding or removing application instances thereof. Following the horizontal scaling operations (step 506), the method returns to applying (and continuing to apply thereinafter) vertical scaling operations if necessary (step 504); [0075] FIG. 6 illustrates an additional flowchart diagram depicting a method 600 for automatic diagonal scaling of workloads in a distributed computing environment, in accordance with aspects of the present invention. The method 600 begins by automatically tracking the resource consumption of each of one or more application instances and compares the consumption of each of the application instances to the resource allocation of the application instance (step 602). The method 600 then continues by computing modification operations (increases or decreases) of resource allocations to the application instances (step 604), in accordance with the results of the comparison in step 602. Next, the computed modification operations are refined according to priorities of the applications and/or application instances, and available resources (step 606). The computed modification operations are then dynamically applied to the application instances respectively (step 608), where the modification operations are of various types, illustrated in steps 610 and 612.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chopra with the teachings of Aronovich to transmit the scaling decision to at least one of a vertical scaler or a horizontal scaler to perform a scaling action on the cloud storage gateway microservice, the storage backend microservice, or both based on the scaling decision, wherein the vertical scaler is configured to determine resources available for an instance of the cloud storage gateway microservice and the horizontal scaler is configured to determine a number of instances of the cloud storage gateway microservice. By dynamically being able to scale resources/instances either vertically or horizontally, actual resource consumption of application instances is automatically tracked and compared to allocated resources of the application instances. Second, the allocated resources and the resource limits thereof are automatically tuned (increased/decreased) according to the compared consumption to allocation of these resources. More particularly, when an application's workload grows, the mechanisms described herein make additional resources available to the application. Similarly, when the workload is reduced, the resources are decreased. Third, vertical and horizontal scaling are used automatically, according to application instance and/or host status and policies. Fourth and lastly, the functionality herein is customizable, efficient, and easy to configure. For example, items that can be set by users may include: maximum bounds on consumption of different resources (e.g., based on historical statistics and cost constraints); minimal bounds on availability of different resources; triggers for determining that a scaling operation is required; and policies for integrating the vertical and horizontal scaling, as discussed in Aronovich ([0030]). This ensures that resource utilization and allocation is done in the most efficient way, ensuring the cloud storage service always has the appropriate number of resources to function.
10. With regard to claim 2, Aronovich further teaches:
wherein the scaling decision includes multiple scaling decisions transmitted by the performance monitoring observer to multiple scalers to take multiple scaling actions ([0071] The method 400 begins (step 402) by tracking resource consumption of each one of a plurality of application instances (step 404), and the tracked resource consumption is compared to a resource allocation of each one of the plurality of application instances (step 406). A plurality of resource reduction operations for allocation of resources assigned to each one of the plurality of application instances is computed and applied (step 408). Idle application instances of the plurality of application instances are identified (step 410), and one or more of the identified idle application instances are terminated (step 412), thereby optimizing application efficiency and resource utilization in the distributed computing environment. The method 400 ends (step 414); [0011] The resource consumption of each of the current application instances 1102 is monitored and tracked, and ultimately compared to the resource allocation of the application instances (again noting that each resource is individually monitored and tracked for each respective application instance). In cases where a particular application instance's load is reduced, vertical reduction operations may then be computed for reducing the amounts of resources allocated and assigned to the application instance (block 1104). Moreover, idle application instances may be identified using the methods previously discussed (idle instances 1106) while the rest of the application instances may be identified as active (active instances 1108). Based on this determination of idle application instances 1106, some or all of the identified idle application instances 1106 may be terminated. That is, horizontal reduction operations are performed to reduce or terminate the idle application instances 1106 (block 1110); Examiner’s Note: A plurality of resource reduction operations is analogous with multiple scaling decisions.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chopra with the teachings of Aronovich wherein the scaling decision includes multiple scaling decisions transmitted by the observer to multiple scalers to take multiple scaling actions. Aronovich teaches of multiple resource reduction operations ([0071]). By having multiple resource reduction operations, or multiple scaling decisions, resources or instances can be properly scaled according to system needs. Aronovich shows that multiple scaling decisions can be applied in order to optimize application efficiency and resource utilization.
11. With regard to claim 4, Aronovich further teaches:
wherein the fixed interval is configured to either increase or decrease based on changes in the reported characteristics ([0079] To define sustained consumption, a time period for qualifying for an allocation change is prescribed. This time period is a time window having a sufficient number of samples remain at sustained consumption within a tier (high tier 704 or low tier 710) to qualify for an allocation change. The time period may be a sliding window over time, and may have a default value. Further defined are a percentage of outlying samples as follows. Sustained consumption is defined, based on these definitions, as having no more than the outlying percentage of the samples outside of either the high tier 704 or the low tier 710 for the duration of the defined time window. For example, assuming a time window of 1 hour and outlying percentage of 10%, if at least 90% of the samples are in one of the tier areas in the last hour, an appropriate increase/decrease action will be computed for the relevant resource; [0083] A time period without an increase operation resets the growing increase 734 functionality. Various functions of the growing increase 734 may be configured, for example, an increase value in a previous increase operation+1 step may be performed (e.g., where the values follow a pattern of 1 step, 2 steps, 3 steps, 4 steps, 5 steps, etc.). In another example, an increase value in a previous increase operation+a linearly growing step may be performed (e.g., where the values follow a pattern of 1 step, 3 steps, 6 steps, 10 steps, 15 steps, 21 steps, etc.); [0084] In still another example, an increase value in a previous operation×2 steps may be performed (e.g., where the values follow a pattern of 1 step, 2 steps, 4 steps, 8 steps, 16 steps, 32 steps, etc.). A limit on increase 736 is further defined to enable the user to control the maximal consumption and associated costs. In some embodiments, there may be multiple limits on increase that are mapped to different time periods (e.g., of day), which may be useful if the cost of resources varies depending on the time the resources are allocated and/or used. Increase operations computed for a resource and an application instance will not exceed the defined value (or values) of the limit on increase 736 for that resource and application instance; Examiner’s Note: The time periods, which are analogous with the fixed interval, are changed in response to time of day or instances of resource increase.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chopra with the teachings of Aronovich wherein the fixed interval is configured to either increase or decrease based on changes in the reported characteristics. By increasing or decreasing the fixed interval based on reported characteristics of the system, scaling decisions can adapt to the system’s current needs, as discussed in Aronovich ([0083]). This ensures that scaling decisions are optimized based on system usage at a certain time. Therefore, ensuring that the system is not exacerbating unnecessary resources at a certain time.
12. With regard to claim 7, Aronovich further teaches:
wherein determining the scaling decision includes calculating whether a value for an input, output, or resource usage metric has exceeded a threshold value ([0093] Case 1—Resource is available: If the vertical increase can be accommodated on the host (while considering resource availability and application priorities) and the application instance limit on increase 736 has not been reached, then a vertical increase operation is applied to the application instance (block 904), and vertical increase operations are subsequently continually applied on application instances which have not crossed the threshold of the limit on increase 736 (block 906) (note the application instances are represented as circles or ovals which grow larger during the vertical increase operations thereby denoting an amount of resources allocated to each respective application instance); [0094] Case 2—Application instance limit on increase 736 has been reached: If the limit on increase 736 of the application instance for the resource has been reached, and the resource is configured as a critical resource for increase (block 908), then the application instance may be scaled further horizontally (block 910) with a defined number of created application instances 912 of the application. The additional application instances may inherit the current allocation of the particular resource of the saturated instance or receive a new base allocation of the resource.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chopra with the teachings of Aronovich wherein determining the scaling decision includes calculating whether a value for an input, output, or resource usage metric has exceeded a threshold value. This allows the system to decide between vertical or horizontal scaling, as discussed in Aronovich ([0093]; [0094]). Doing so allows for dynamic scaling, which helps the system efficiently allocate or deallocate resources or instances according to system needs.
13. Regarding claim 8, it is rejected under the same reasoning as claim 1 above. Therefore, it is rejected under the same rationale.
14. Regarding claim 9, it is rejected under the same reasoning as claim 2 above. Therefore, it is rejected under the same rationale.
15. Regarding claim 13, it is rejected under the same reasoning as claim 4 above. Therefore, it is rejected under the same rationale.
16. Regarding claim 14, it is rejected under the same reasoning as claim 7 above. Therefore, it is rejected under the same rationale.
17. Regarding claim 15, it is rejected under the same reasoning as claim 1 above. Therefore, it is rejected under the same rationale.
18. Regarding claim 16, it is rejected under the same reasoning as claim 2 above. Therefore, it is rejected under the same rationale.
19. Regarding claim 19, it is rejected under the same reasoning as claim 7 above. Therefore, it is rejected under the same rationale.
20. With regard to claim 20, Aronovich further teaches:
wherein the performance monitoring observer is configured to coordinate the scaling action to prevent scaling interference between the vertical scaler and the horizontal scaler ([0030] The present invention employs functionality to more efficiently optimize and utilize resources in distributed computing environments by way of automatic diagonal scaling. That is, the disclosed embodiments employ efficient mechanisms for automatic diagonal scaling, having the following exemplary specifications. First, actual resource consumption of application instances is automatically tracked and compared to allocated resources of the application instances. Second, the allocated resources and the resource limits thereof are automatically tuned (increased/decreased) according to the compared consumption to allocation of these resources. More particularly, when an application's workload grows, the mechanisms described herein make additional resources available to the application. Similarly, when the workload is reduced, the resources are decreased. Third, vertical and horizontal scaling are used automatically, according to application instance and/or host status and policies. Fourth and lastly, the functionality herein is customizable, efficient, and easy to configure. For example, items that can be set by users may include: maximum bounds on consumption of different resources (e.g., based on historical statistics and cost constraints); minimal bounds on availability of different resources; triggers for determining that a scaling operation is required; and policies for integrating the vertical and horizontal scaling; [0072] The general approach of diagonal scaling is to scale application instances vertically (allocating or de-allocating resources), and when an application instance or a host are saturated, or when an application instance is idle, to then scale horizontally (create or remove application instances).).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chopra with the teachings of Aronovich wherein the performance monitoring observer is configured to coordinate the scaling action to prevent scaling interference between the vertical scaler and the horizontal scaler. Aronovich teaches of a diagonal scaler that uses both vertical and horizontal scaling dynamically. Applications are scaled vertically when an application instance is saturated. In contrast, an application is scaled horizontally when an application is idle. This dynamic scaling helps ensure that applications are scaled according to resource usage and needs, which would prevent vertical and horizontal scalers to interfere with each other. The unified algorithmic mechanism that automatically applies both vertical and horizontal scaling, creating a synergy between vertical and horizontal scaling (i.e., diagonal scaling), to optimize the efficiency of applications and platforms, as discussed in Aronovich ([0025]).
21. Regarding claim 21, it is rejected under the same reasoning as claim 20 above. Therefore, it is rejected under the same rationale.
22. Regarding claim 22, it is rejected under the same reasoning as claim 20 above. Therefore, it is rejected under the same rationale.
23. Claims 5-6, 11-12, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Chopra et al. US 10635334 B1 and Aronovich US 20190158424 A1, as applied in claim 1, in further view of Chang et al. US 20140366155 A1.
24. With regard to claim 5, Chopra and Aronovich teach the system of claim 1 but fail to explicitly teach wherein the cloud storage gateway microservice is configured to compress or decompress the data related to [[a]] the request when processing the request.
However, in analogous art, Chang teaches:
wherein the cloud storage gateway microservice is configured to compress or decompress the data related to [[a]] the request when processing the request ([0045] Cloud storage gateway 46 can include a cloud storage gateway (CSG) feature module 66 that provides data security features for maintaining data confidentiality, data integrity, and/or data availability of data stored on cloud 14. The data security features can include data encryption, data compression, data deduplication, data replication, other data security features, or a combination thereof. In various embodiments, CSG feature module 68 enables cloud storage gateway 46 to encrypt and decrypt application workloads and/or data migrating from virtual machines of enterprise 12 and/or cloud 14 (for example, VMs 28(1)-28(N) and/or VMs 40(1)-40(P), respectively) to cloud storage 62. Such data encryption feature can ensure data integrity of stored data while in motion and in rest. In various embodiments, the data encryption feature allows a cloud user to generate their own private encryption key(s). For example, enterprise network 12 can store and manage a private encryption key(s), and cloud storage gateway 46 can use the private encryption key(s) to encrypt data before it is stored at cloud storage 62. In such instances, cloud storage gateway 46 can provide the data encryption feature at the cloud 14.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chopra and Aronovich with the teachings of Chang wherein the cloud storage gateway microservice is configured to compress or decompress the data related to the request when processing the request. Both Chopra and Chang teach of cloud storage services. In Chang, cloud storage gateways can compress data. This serves as a means for data security. In particular, compression and decompression relate to data availability of data stored on a cloud, as discussed in Chang ([0045]). By compressing and decompressing data, it allows more data to be stored in the same amount of space. This allows storage to be more efficient and provide the cloud storage gateway optimal use of its storage space.
25. With regard to claim 6, Chopra and Aronovich teach the system of claim 1 but fail to explicitly teach wherein the cloud storage gateway microservice is configured to encrypt or decrypt the data related to [[a]] the request when processing the request.
However, in analogous art, Chang further teaches:
wherein the cloud storage gateway microservice is configured to encrypt or decrypt the data related to [[a]] the request when processing the request ([0045] Cloud storage gateway 46 can include a cloud storage gateway (CSG) feature module 66 that provides data security features for maintaining data confidentiality, data integrity, and/or data availability of data stored on cloud 14. The data security features can include data encryption, data compression, data deduplication, data replication, other data security features, or a combination thereof. In various embodiments, CSG feature module 68 enables cloud storage gateway 46 to encrypt and decrypt application workloads and/or data migrating from virtual machines of enterprise 12 and/or cloud 14 (for example, VMs 28(1)-28(N) and/or VMs 40(1)-40(P), respectively) to cloud storage 62. Such data encryption feature can ensure data integrity of stored data while in motion and in rest. In various embodiments, the data encryption feature allows a cloud user to generate their own private encryption key(s). For example, enterprise network 12 can store and manage a private encryption key(s), and cloud storage gateway 46 can use the private encryption key(s) to encrypt data before it is stored at cloud storage 62. In such instances, cloud storage gateway 46 can provide the data encryption feature at the cloud 14; [0046] The architecture of cloud storage gateway 46 is intended to facilitate data encryption services that can enhance cloud storage services of communication system 10. In various embodiments, cloud storage gateway 46 can intercept data from VM 40, relay the data to cloud storage 62 (for example, over a secure socket layer (SSL) session 70), apply an encryption function to the data, thereby generating encrypted data 72, and write the encrypted data 72 to cloud storage 62. In the reverse direction, in various embodiments, cloud storage gateway 46 can decrypt the encrypted data 72 before fulfilling a data request (such as a read request) from VM 40.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chopra and Aronovich with the teachings of Chang wherein the cloud storage gateway microservice is configured to encrypt or decrypt the data related to the request when processing the request. Both Chopra and Chang teach of cloud storage services. In Chang, encrypting and decrypting the data related to the request in a cloud storage gateway adds a layer of security to user data. This helps facilitate secure migration of data between the enterprise storage and the cloud storage can include providing a secure tunnel between the virtual machine and the cloud storage gateway in the cloud, as discussed in Chang ([0014]). By providing this extra security, user data is protected from malicious attacks.
26. Regarding claim 11, it is rejected under the same reasoning as claim 5 above. Therefore, it is rejected under the same rationale.
27. Regarding claim 12, it is rejected under the same reasoning as claim 6 above. Therefore, it is rejected under the same rationale.
28. Regarding claim 17, it is rejected under the same reasoning as claim 5 above. Therefore, it is rejected under the same rationale.
29. Regarding claim 18, it is rejected under the same reasoning as claim 6 above. Therefore, it is rejected under the same rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AN-AN N NGUYEN whose telephone number is (571)272-6147. The examiner can normally be reached Monday-Friday 8:00-5:00 ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, AIMEE LI can be reached at (571) 272-4169. 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.
/AN-AN NGOC NGUYEN/Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195