DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-6, 8-16, and 18-20 are pending. Claims 7 and 17 are cancelled. Prior rejections of claims 7 and 17 are moot.
Response to Arguments
Regarding Double Patenting:
The claimed invention as amended is determined to be patently distinct from its co-pending applications. The provisional non-statutory obviousness double patenting rejections are currently withdrawn.
Regarding 35 U.S.C. 112:
Applicant’s amendments and arguments regarding the rejection of claims 1-6, 8-16, and 17-20 under 35 U.S.C. 112(b) have been fully considered and are found to be persuasive. The prior rejections of claims 1-6, 8-16, and 17-20 under 35 U.S.C. 112(b) are withdrawn.
Regarding: Prior Art Rejections:
Applicant’s amendments and arguments regarding the rejection of claims 1-20 under 35 U.S.C. 103 have been fully considered and are moot under a new ground of rejection necessitated by amendment.
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.
Claims 1-2, 4-5, 8-12, 14-15, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lepcha et al. US 20180181390 A1 in view of Saka et al. US 20200210223 A1 in view of Matskevich et al. US 20140331233 A1 in view of Janssens et al. US 20140258546 A1.
Lepcha, Saka, and Matskevich are cited in a prior office action.
Regarding claim 1, Lepcha teaches the invention substantially as claimed including:
A method, comprising:
analyzing a load factor regarding a new message as a workload for one or more actors in a data storage platform (Fig. 1A, 110, 120; Fig. 1B, 100; [0010] a first microservice may be associated with a first number of instances (i.e., actors) that are executing; [0046] receiving information identifying a set of tasks (i.e., workload), associated with a microservices application to be executed (block 410); [0053] In this way, scheduling platform 220 may receive information that identifies tasks to be scheduled for execution, and may determine an execution time of the tasks based on the model and parameters associated with the tasks (i.e., analyzing a load factor)); [0027] Cloud computing environment 222 may provide … storage … services),;
applying one or more criteria to an output of the load factor analyzing (Fig. 1C, 140; [0049] “scheduling platform 220 may determine a threshold (e.g., a threshold amount of time) based on the SLA; [0068] “scheduling platform 220 may determine whether the execution time satisfies a threshold”);
based on the applying the one or more criteria, determining whether or not additional actors are needed to perform the workload (Fig. 1D, 150; [0069] if the execution time does not satisfy the threshold (block 430—NO), then process 400 may include adjusting a number of instances, of a microservice, of the microservices application (block 440));
determining a number of reserve actors for use in accommodating unanticipated, and dynamic, changes occurring in the data storage platform during execution of one or more workloads, and the one or more changes comprise a change to one or more workload related factors, and the workload related factors include load factors, workload performance patterns, and workload types ([0056] a parameter may include information that identifies a type of microservices application associated with the set of tasks (e.g., “type of microservices application”). Additionally, or alternatively, a parameter may refer to information that identifies a number of tasks to be executed (e.g., “number of tasks”). Additionally, or alternatively, a parameter may refer to information that identifies an elapsed time associated with an execution of the set of tasks, such as an amount of time that has elapsed since the start of the execution of the set of tasks (e.g., “elapsed time”));
when it is determined that the additional actors are needed to perform the workload, spawning the additional actors (Fig 1D; [0018] As shown in FIG. 1D, and by reference number 150, the scheduling platform may selectively adjust a number of instances, of a microservice, based on the execution time. For example, as shown, the scheduling platform may adjust a number of instances of microservice 1 (e.g., increase from 15 to 30)),
load balancing the workload across a group that includes both the one or more actors and the additional actors that have been spawned ([0019] more subtasks, associated with microservices 1, may execute in parallel, (i.e., load balanced across 30 instances vs 15 instances) thereby decreasing an execution time associated with the set of tasks and thereby conserving processor and/or memory resources of network devices and/or scheduling platform),
Lepcha does not explicitly teach wherein each actor of the one or more actors includes a respective queue for messages to be serially performed by that actor.
However, Saka teaches wherein each actor of the one or more actors includes a respective queue for messages to be serially performed by that actor (Fig 3; [0026] Task executors 125, in various embodiments, include a set of task queues 126 and a set of corresponding thread pools 127 having threads executable to process tasks that are enqueued in those task queues 126) .
It would have been obvious to a person having ordinary skill in the art before the
effective filing date of the invention to have combined Saka’s task queueing system with the system of Lepcha. A person of ordinary skill in the art would have been motivated to make this combination to provide Lepcha’s system with the advantage of improving processing efficiency (see Saka [0019-0020] the thread may retrieve another task from its task queue for processing without waiting for a response from the downstream service. After the one or more tasks have been processed, the computer system may provide a response to the request that includes a result from performing the operation … instead of a thread remaining idle while it waits for a response (as done in prior approaches), the thread can perform other work such as retrieving and performing another task).
Lepcha and Saka do not explicitly teach determining a number of reserve actors for use in accommodating unanticipated, and dynamic, changes; spawning the reserve actors; the group does not include the reserve actors; detecting an unanticipated change in a condition in the data storage platform; and in response to the detecting of the unanticipated change, deploying one of the reserve actors to perform part of a job associated with the changed condition.
However, Matskevich teaches determining a number of reserve actors for use in accommodating unanticipated, and dynamic, changes ([0006] The method includes determining a total number of a computing system's idle processing units available for provision to existing tasks, including a set of processing units that can be provided for executing regular tasks and a set of processing units that constitute a reserve pool; [0021] A set of processing units constituting the reserve pool (as reserve actors) can be expressed, for example, as a percentage of the total number of processing units); spawning the reserve actors ([0058] The example in FIG. 5 shows that with the value ERP=10%, 10 processing units are reserved as the reserve pool 570); load balancing the workload across a group that does not include the reserve actors (Fig 5 510-560; [0058] The described task distribution method allocates 45 processing units (90*50%) to the first task. Then, it assigns 10 processing units to the second task and 17 processing units (90-45-10)*50%) to the third task. Then, one processing unit is allocated to the fourth and fifth tasks. After that, 8 processing units ((90-45-10-17-1-1)*50%) are allocated to the sixth task. Eight processing units remain available for allocation to new tasks that may be fed into the queue. Eight processing units can be used both for executing sequential tasks and for threading them);
detecting an unanticipated change in a condition in the data storage platform (Fig 1 120 Have all general task processing units been assigned to tasks?); and in response to the detecting of the unanticipated change, deploying one of the reserve actors to perform part of a job associated with the changed condition (Fig 1 140 Assign at least one emergency ration processing unit to unassigned task).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Lepcha and Saka with Matskevich because Matskevich’s teaching of a pool of reserve processing units taking on workload would have provided Lepcha and Saka’s system with the advantage and capability to dynamically allocate reserved instances of a microservice as needed thereby improving short term system scalability (see Matskevich [0006] The method includes determining a total number of a computing system's idle processing units available for provision to existing tasks, including a set of processing units that can be provided for executing regular tasks and a set of processing units that constitute a reserve pool).
While Lepcha as well as Matskevich teach changes to conditions which require the dynamic allocation of more resources, it is not explicitly taught that the conditions are unanticipated.
However, Janssens teaches unanticipated change in a condition ([0003] Some key advantages emerging from dynamic right-sizing include (1) the ability to reduce the services' operational cost and (2) the ability to gracefully handle unanticipated load surges without introducing opportunity loss by compromising the service's SLA; [0004] sporadic unanticipated load surges (caused by events with a significant social impact) or anticipated load spikes (e.g. caused by New Year's Eve texting)).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to have combined Janssens’ unanticipated load surges with the system of Lepcha, Saka, and Matskevich. A person of ordinary skill in the art would have been motivated to make this combination to provide Lepcha, Saka, and Matskevich’s system with the advantage of cost effective handling of unexpected demand surges (see Janssens [0005] Accordingly, it is an object of embodiments of the present invention to provide methods and apparatus for proactive scaling of elastic (telecommunication) systems that more efficiently balance the tradeoff between reducing infrastructure cost, and providing enough overcapacity to deal with sudden increases in load).
Regarding claim 2, Lepcha, Saka, Matskevich, and Janssens teach the method as recited in claim 1.
While Lepcha teaches a number of additional actors, Lepcha does not explicitly teach wherein the number of the reserve actors is a function of the number of additional actors.
However, Matskevich teaches wherein the number of the reserve actors is a function of the number of actors ([0021] A set of processing units constituting the reserve pool can be expressed, for example, as a percentage of the total number of processing units).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have substituted the total number of processing units of Matskevich’s formula to determine the reserve pool size with the additional instances of Lepcha to obtain a method that calculates reserve actors based on the amount of newly added actors. The results of this combination are predictable because the number of reserved actors available to perform tasks will be based on a fixed percentage of the number of determined additional actors.
Regarding claim 4, Lepcha, Saka, Matskevich, and Janssens teach the method as recited in claim 1.
Lepcha further teaches wherein one or more of the actors comprises a microservice, or an instance of a microservice ([0018] the scheduling platform may selectively adjust a number of instances, of a microservice).
Regarding claim 5, Lepcha, Saka, Matskevich, and Janssens teach the method as recited in claim 1.
Lepcha further teaches wherein the spawning and load balancing of the workload are performed automatically, as needed, based on the applying of the one or more criteria (Fig 4 Steps 430-440; [0008] FIG. 4 is a flow chart of an example process for automatically adjusting a number of instances of a microservice based on an execution time of a set of tasks).
Regarding claim 8, Lepcha, Saka, Matskevich, and Janssens teach the method as recited in claim 1.
Matskevich further teaches wherein the deploying of the reserve actor is performed automatically in response to the detecting of the condition (Fig 1 140; [0028] when there are no such processing units, the next task is assigned to processing units from the reserve pool (step 140)).
Regarding claim 9, Lepcha, Saka, Matskevich, and Janssens teach the method as recited in claim 1.
Matskevich further teaches wherein after the condition terminates, the deployed reserve actor is returned to a 'reserved' status (Fig 1 120, 140; [0059] processing units from the reserve pool are not assigned to tasks while there are idle regular processing units; Examiner notes: a reserve processing unit executing a task is no longer to be used for task processing once idle processing units are available).
Regarding claim 10, Lepcha, Saka, Matskevich, and Janssens teach the method as recited in claim 1.
Matskevich further teaches wherein the reserve actor is deployed based on a relative weight of the job associated with the changed condition (Fig 3 340; [0042] selecting the queue with the highest priority (340); [0048] complex tasks with high priority are processed first, followed by lower priority tasks), and use of the reserve actor accelerates performance of that job relative to how quickly the job would have been performed if the reserve actor had not been deployed ([0062] the task will be distributed between these 2 processing units, and processing units from the reserve pool 604 will be assigned to the next task from the queue since processing units from the reserve pool 604 are allocated only when there are no idle regular processing units 602).
Regarding claim 11, it is the non-transitory storage medium of claim 1. Therefore, it is rejected for the same reasons as claim 1.
Lepcha further teaches a non-transitory storage medium having stored therein instructions that are executable by one or more hardware processors to perform operations ([0003] a non-transitory computer-readable medium may store one or more instructions that, when executed by one or more processors of a device, cause the one or more processors to …).
Regarding claims 12-15 and 18-20, they are the non-transitory storage media of claims 2-5 and 8-10 respectively. Therefore, they are rejected for the same reasons as claims 2-5 and 8-10 respectively.
Claims 3, 6, 13 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Lepcha et al. US 20180181390 A1 in view of Saka et al. US 20200210223 A1 in view of, in view of Matskevich et al. US 20140331233 A1 in view of Janssens et al. US 20140258546 A1 in view of Muehge et al. US 20200174892 A1.
Muehge is cited in a previous office action.
Regarding claim 3, Lepcha, Saka, Matskevich, and Janssens teach the method as recited in claim 1.
Lepcha and Matskevich do not explicitly teach wherein the workload comprises servicing copy discovery notifications received from one or more hosts.
However, analogous art by Muehge teaches wherein the workload comprises servicing copy discovery notifications received from one or more hosts ([0087] backup requests received).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Lepcha, Saka, Matskevich, Janssens with Muehge because Muehge’s teaching of backup request processing system would have provided the system of Lepcha, Saka, Matskevich, Janssens with the advantage and capability to improve the resource allocation in a data backup storage system by improving awareness about the number of backups that the system is assigned to perform (see Muehge [0001] The present invention relates to resource allocation in a backup environment, and more specifically, this invention relates to resource allocation for backup operations performed on a data storage system; [0087] determining that the number of backup requests received is more than the data storage system can process at one time).
Regarding claim 6, Lepcha, Saka, Matskevich, and Janssens teach the method as recited in claim 1.
Lepcha, Matskevich, and Saka do not explicitly teach wherein determining whether or not any additional actors are needed comprises measuring a queue performance of one or more of the actors.
However, analogous art by Muehge teaches measuring a queue performance of one or more of the actors ([0057] the measured actual wait time information may indicate how long the backup request has been in the backup queue waiting to be fulfilled).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Lepcha, Saka, Matskevich, Janssens with Muehge because Muehge’s teaching of measuring a queue wait time would have provided the system of Lepcha, Saka, Matskevich, Janssens with the advantage and capability to improve the resource allocation in a data backup storage system by improving awareness about the timeliness of the backups that the system is assigned to perform and adjust resources according to how long the backup requests are in the queue (Muehge [0001] The present invention relates to resource allocation in a backup environment, and more specifically, this invention relates to resource allocation for backup operations performed on a data storage system; [0057] Measured actual wait time information may specify how long an associated backup request has been waiting to be fulfilled, e.g., as determined by a server of the data storage system).
Regarding claims 13 and 16, they are the non-transitory storage media of claims 3 and 6 respectively. Therefore, they are rejected for the same reasons as claims 3 and 6 respectively.
Conclusion
Any inquiry concerning this communication or earlier communications from the
examiner should be directed to HARRISON LI whose telephone number is (703) 756-1469. The
examiner can normally be reached Monday-Friday 9:00am-5:30pm 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 on 571-272-4169. 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.
/H.L./
Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights