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
Claims 1-2 and 15 are amended.
Claims 1-7 and 15-27 are pending.
Claims 8-14 are canceled.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 15-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 15 recites “adjust the sampling interval, by throttling a polling interval”, while the specification describes a sampling interval in Par. 34 and “the polling interval may be throttled” in Par. 58, it does not describe adjusting the sampling interval, by throttling a polling interval. The specification does not describe nor is it clear how the two elements are interacting nor does it describe the sampling interval being made up of a polling interval.
Claims 16-20 are rejected based on their inherited deficiencies.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 15-20 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 15 recites the limitation "the predetermined policy threshold”. There is insufficient antecedent basis for this limitation in the claim.
Claims 16-20 are rejected based on their inherited deficiencies.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-4, 6, 15-18 and 20-26 are rejected under 35 U.S.C. 103 as being unpatentable over Purushothaman (US 10021013 B2) hence forth Purus, in view of Byrd (US 20060047805 A1).
In claim 1, Purus discloses a method for managing overhead for performance data (Column 1 Lines 15-26 “tracking the performance”, Column 7 Lines 28-35 “core parameters may include, but are not limited to, one or more of Central Processing Unit (CPU) usage percentage; memory usage percentage or amount; file system usage/consumption of disk space percentage or amount, processes hosted on the server (i.e., are the processes available, are they running properly, are they occupying proper memory space, are they using proper CPU capacity and the like)” examiner considers these parameters to be said overhead), the method comprising: executing a performance profiling tool (Fig. 2, 320) on a computing system (Fig. 2); executing an application on the computing system (Column 1 Lines 27-35 “applications running on the server”); collecting, at a sampling interval (Column 10 Lines 17-27 “monitoring and analyzing real-time data and the rate”), performance data about the application from the performance profiling tool (Column 1 Lines 27-35 ‘monitoring of servers… applications running on the server’ Column 6 Lines 21-34 “applications hosted thereon”); storing the performance data in a database (Fig. 2 304); measuring an impact of the performance profiling tool on the application (Column 1 Lines 20-35, Column 6 Lines 35-53, Column 7 Lines 28-35, “optimizing server parameter thresholds herein discussed, the present invention provides for a stable server environment across the entirety of an enterprise, such that, each server in the enterprise is capable of hosting relevant applications” examiner notes that while it does not explicitly recite “an impact of the performance tool”, one of ordinary skill would infer that as the performance requires resources to run thus reduces resources available to the other programs and applications while staying below the thresholds); applying at least one predefined policy that limits the impact of the performance profiling tool on the application (Column 8 Lines 1-17 “optimize (i.e., adjust), over time, the threshold values based on changes in the conditions experienced by the plurality of servers (e.g., increase/decrease in server utilization and the like)”) based on priority levels of the application (Column 8 Lines 1-17 “the relevant importance of each of the core parameters in comparison to the core parameter being considered for optimization/adjustment”), wherein the at least one predefined policy specifies different impact thresholds for applications having different priority levels (Column 8 Lines 1-17 “optimization of the threshold value of one core parameter is dependent upon the threshold values set of the other parameters” i.e. each parameter has their own threshold); and adjusting the interval at which the performance profiling tool operates (Column 9 Lines 50-65 “optimization/adjustment is dynamically”) in order to keep the impact of the performance profiling tool on the application below a predetermined policy threshold (Column 9 Lines 50-65 “threshold values”, “increase/decrease in CPU utilization, memory utilization and the like”); wherein the impact is based on a degradation in performance of the executed application caused by execution of the performance profiling tool (Column 9 Lines 50-65 “optimize (i.e., adjust), over time, the threshold values based on changes in the conditions experienced by the plurality of servers (e.g., increase/decrease in server utilization and the like”).
Purus odes not explicitly disclose adjusting the sampling interval in order to keep the impact of the performance profiling tool on the application below a predetermined policy threshold based, at least in part, on the measured impact of the performance profiling tool on the application and the at least one predefined policy (emphasis added).
Byrd teaches applying at least one predefined policy that limits the impact of the performance profiling tool on the application based on priority levels (Par. 81 “adjust the priorities for scheduling of the activity monitors”, “impact of monitoring to be dynamically adjusted”, and Par. 136 “higher priority access to the hardware”); and adjusting the sampling interval in order to keep the impact of the performance profiling tool on the application below a predetermined policy threshold (Par. 81 “adjust the priorities for scheduling of the activity monitors”) based, at least in part, on the measured impact of the performance profiling tool on the application (Par. 81 “he impact of monitoring to be dynamically adjusted as needed”) and the at least one predefined policy (Par. 81 “priorities”); wherein the impact is based on a degradation in performance of the executed application caused by execution of the performance profiling tool (Par. 130 “process monitor 516 and FS monitor 522 may be executed periodically in order to minimize the impact of the monitors 516, 518, 520, 522 on the performance of the target computer system 500”).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled that adjusting the sampling interval in order to keep the impact of the performance profiling tool on the application below a predetermined policy threshold based, at least in part, on the measured impact of the performance profiling tool on the application and the at least one predefined policy based on the teaching of Byrd in combination with the disclosure of Purus in order to control the impact of the monitoring as needed (Byrd Par. 81), thus leading to a more dynamic system.
In claim 2, Purus further discloses providing the performance data to one or more system monitors (Fig. 2 310 and 320); receiving feedback from the system monitors being used to control operation of the performance profiling tool (Fig. 3, 402, 404, and 408); and adjusting the interval based on the feedback (Fig. 4, 408).
Purus does not explicitly disclose adjusting the sampling interval based on the feedback.
Byrd teaches adjusting the sampling interval based on the feedback (Par. 81 “adjust the priorities for scheduling of the activity monitors” “the impact of monitoring to be dynamically adjusted as needed”).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled that adjusting the sampling interval based on the feedback based on the teaching of Byrd in combination with the disclosure of Purus in order to control the impact of the monitoring as needed (Byrd Par. 81), thus leading to a more dynamic system.
In claim 3, Purus further discloses providing the performance data to one or more system monitors (Fig. 2 310 and 320); receiving feedback from the system monitors (Fig. 3, 402, 404); and adding or removing one or more performance measures from being collected based on the feedback (Column 2 Lines 8-19 “allowing parameters to be chosen and thresholds assigned on a per-server basis” examiner notes that while “most, if not all” use the same core parameters, some still can be assigned on a per-server basis ).
In claim 4, Purus in view of Byrd discloses all of claim 2. Purus further discloses wherein one of the system monitors is a system health monitor and/or a system security monitor (Column 9 Lines 1-20 “basic health monitoring”).
In claim 6, Purus in view of Byrd discloses all of claim 2. Purus further discloses providing recommendations to a user regarding application optimizations based on the performance data stored in the database (Column 9 Lines 26-35 “a user”, “at the bequest of the enterprise”).
In claim 15, Purus discloses an overhead management system (Column 1 Lines 15-26 “tracking the performance”, Column 7 Lines 28-35 “core parameters may include, but are not limited to, one or more of Central Processing Unit (CPU) usage percentage; memory usage percentage or amount; file system usage/consumption of disk space percentage or amount, processes hosted on the server (i.e., are the processes available, are they running properly, are they occupying proper memory space, are they using proper CPU capacity and the like)” examiner considers these parameters to be said overhead) having at least one processor (Fig. 2, 306), the system configured to: execute a performance profiling tool (Fig. 2, 320) on a computing system (Fig. 2); execute an application on the computing system (Column 1 Lines 27-35 “applications running on the server”); collect, at a sampling interval (Column 10 Lines 17-27 “monitoring and analyzing real-time data and the rate”), performance data about the application from the performance profiling tool (Column 1 Lines 27-35 ‘monitoring of servers… applications running on the server’ Column 6 Lines 21-34 “applications hosted thereon”); storing the performance data in a database (Fig. 2 304); measure an impact of the performance profiling tool on the application (Column 1 Lines 20-35, Column 6 Lines 35-53, Column 7 Lines 28-35, “optimizing server parameter thresholds herein discussed, the present invention provides for a stable server environment across the entirety of an enterprise, such that, each server in the enterprise is capable of hosting relevant applications” examiner notes that while it does not explicitly recite “an impact of the performance tool”, one of ordinary skill would infer that as the performance requires resources to run thus reduces resources available to other programs and applications while staying below the thresholds); applying at least one predefined policy that limits the impact of the performance profiling tool on the application (Column 8 Lines 1-17 “optimize (i.e., adjust), over time, the threshold values based on changes in the conditions experienced by the plurality of servers (e.g., increase/decrease in server utilization and the like)”) based on priority levels of the application (Column 8 Lines 1-17 “the relevant importance of each of the core parameters in comparison to the core parameter being considered for optimization/adjustment”) and adjust an interval (Column 9 Lines 50-65 “optimization/adjustment is dynamically”) in order to keep the impact of the performance profiling tool on the application below a predetermined policy threshold (Column 9 Lines 50-65 “threshold values”, “increase/decrease in CPU utilization, memory utilization and the like”); wherein the impact is based on a degradation in performance of the executed application caused by execution of the performance profiling tool (Column 9 Lines 50-65 “optimize (i.e., adjust), over time, the threshold values based on changes in the conditions experienced by the plurality of servers (e.g., increase/decrease in server utilization and the like”).
Purus odes not explicitly disclose adjusting the sampling interval by throttling a polling interval to reduce the impact when measured impact exceeds the predetermined policy threshold, in order to keep the impact of the performance profiling tool on the application below a predetermined policy threshold based, at least in part, on the measured impact of the performance profiling tool on the application and the at least one predefined policy (emphasis added).
Byrd teaches applying at least one predefined policy that limits the impact of the performance profiling tool on the application based on priority levels (Par. 81 “adjust the priorities for scheduling of the activity monitors”, “impact of monitoring to be dynamically adjusted”, and Par. 136 “higher priority access to the hardware”); and adjusting the sampling interval by throttling a polling interval (See Fig. 7, 704-702, Par. 145 examiner notes when a predefined event occurs, the process reinitiates which activity monitors are used) to reduce the impact when measured impact exceeds the predetermined policy threshold (Par. 104-106, “start or stop certain activity monitors 320a-n according to various criteria”, “predefined event may include the starting or stopping of a certain process, mounting of a peripheral device, an error condition”), in order to keep the impact of the performance profiling tool on the application below a predetermined policy threshold (Par. 81 “adjust the priorities for scheduling of the activity monitors”) based, at least in part, on the measured impact of the performance profiling tool on the application (Par. 81 “the impact of monitoring to be dynamically adjusted as needed”) and the at least one predefined policy (Par. 81 “priorities”); wherein the impact is based on a degradation in performance of the executed application caused by execution of the performance profiling tool (Par. 130 “process monitor 516 and FS monitor 522 may be executed periodically in order to minimize the impact of the monitors 516, 518, 520, 522 on the performance of the target computer system 500”).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled that adjusting the sampling interval in order to keep the impact of the performance profiling tool on the application below a predetermined policy threshold based, at least in part, on the measured impact of the performance profiling tool on the application and the at least one predefined policy based on the teaching of Byrd in combination with the disclosure of Purus in order to control the impact of the monitoring as needed (Byrd Par. 81), thus leading to a more dynamic system.
In claim 16, Purus further discloses provide the performance data to one or more system monitors (Fig. 2 310 and 320); receive feedback from the system monitors (Fig. 3, 402, 404); and adjust the interval at which the performance profiling tool operates based on the feedback (Fig. 4, 408).
Purus does not explicitly disclose adjusting the sampling interval based on the feedback.
Byrd teaches adjusting the sampling interval based on the feedback (Par. 81 “adjust the priorities for scheduling of the activity monitors” “the impact of monitoring to be dynamically adjusted as needed”).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled that adjusting the sampling interval based on the feedback based on the teaching of Byrd in combination with the disclosure of Purus in order to control the impact of the monitoring as needed (Byrd Par. 81), thus leading to a more dynamic system.
In claim 17, Purus further discloses provide the performance data to one or more system monitors (Fig. 2 310 and 320); receive feedback from the system monitors (Fig. 3, 402, 404); and add or remove one or more performance measures from being collected based on the feedback (Column 2 Lines 8-19 “allowing parameters to be chosen and thresholds assigned on a per-server basis” ” examiner notes that while “most, if not all” use the same core parameters, some still can be assigned on a per-server basis).
In claim 18, Purus in view of Byrd discloses all of claim 16. Purus further discloses wherein one of the system monitors is a system health monitor and/or a system security monitor (Column 9 Lines 1-20 “basic health monitoring”).
In claim 20, Purus in view of Byrd discloses all of claim 15. Purus further discloses providing recommendations to a user regarding application optimizations based on the performance data stored in the database (Column 9 Lines 26-35 “a user”, “at the bequest of the enterprise”).
In claim 21, Purus discloses a system for managing overhead (Column 7 Lines 28-35 “core parameters may include, but are not limited to, one or more of Central Processing Unit (CPU) usage percentage; memory usage percentage or amount; file system usage/consumption of disk space percentage or amount, processes hosted on the server (i.e., are the processes available, are they running properly, are they occupying proper memory space, are they using proper CPU capacity and the like)” examiner considers these parameters to be said overhead) for performance data (Fig. 2) comprising: a server (See title, abstract) including at least one processor (Fig. 2, 306) and at least one computer readable storage medium (Fig. 2, 304); a management application maintained on the server (Fig. 2, 310), the management application including instructions stored on the computer readable storage medium and executable by the at least one processor; at least one performance tool configured to generate performance data (Column 1 Lines 27-35 ‘monitoring of servers… applications running on the server’); at least one collection module configured to collect, at a sampling interval (Column 10 Lines 17-27 “monitoring and analyzing real-time data and the rate”), performance data about an application from the performance tool (Column 1 Lines 27-35 ‘monitoring of servers… applications running on the server’ Column 6 Lines 21-34 “applications hosted thereon”); at least one database communicatively coupled to the management application (Fig. 2, 304), the at least one database storing the performance data (Fig. 2, 304); and at least one feedback module configured to analyze the performance data and generate feedback (Fig. 3, 402, 404); wherein the management application is configured to dynamically adjust the sampling of the performance data based (Column 9 Lines 50-65 “optimization/adjustment is dynamically”), at least in part, on feedback received from the at least one feedback module (Column 9 Lines 50-65 “threshold values”, “increase/decrease in CPU utilization, memory utilization and the like”); wherein the impact is based on a degradation in performance of the executed application caused by execution of the performance profiling tool (Column 9 Lines 50-65 “optimize (i.e., adjust), over time, the threshold values based on changes in the conditions experienced by the plurality of servers (e.g., increase/decrease in server utilization and the like”).
Purus does not explicitly disclose wherein the management application is configured to dynamically adjust the sampling interval of the performance data based, at least in part, on feedback received from the at least one feedback module including a measured impact of the performance tool on the application.
Byrd teaches adjusting wherein the management application is configured to dynamically adjust the sampling interval of the performance data based, at least in part, on feedback received from the at least one feedback module including a measured impact of the performance tool on the application (Par. 81 “the impact of monitoring to be dynamically adjusted as needed”) and the at least one predefined policy (Par. 81 “priorities”); wherein the impact is based on a degradation in performance of the executed application caused by execution of the performance profiling tool (Par. 130 “process monitor 516 and FS monitor 522 may be executed periodically in order to minimize the impact of the monitors 516, 518, 520, 522 on the performance of the target computer system 500”).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled that wherein the management application is configured to dynamically adjust the sampling interval of the performance data based, at least in part, on feedback received from the at least one feedback module including a measured impact of the performance tool on the application based on the teaching of Byrd in combination with the disclosure of Purus in order to control the impact of the monitoring as needed (Byrd Par. 81), thus leading to a more dynamic system.
In claim 22, Purus further discloses wherein the at least one feedback module includes a real-time performance analysis engine, a recommendation engine, a system health monitor, or a system security monitor (Column 9 Lines 1-20 “basic health monitoring”, Fig. 2, 312 “monitor for compliance”, Column 10 Lines 17-27 “monitoring and analyzing real-time data and the rate” abstract “alerts may be generated”).
In claim 23, Purus further discloses at least one performance counter configured to generate performance metrics associated with the application (Column 10 Line 60 – Column 11 Line 5).
In claim 24 Purus in view of Byrd discloses all of claim 23. Purus further discloses wherein the management application is configured to adjust which one or more of the at least one performance counters are collected based at least in part on feedback received from the at least one feedback module (Column 10 Line 60 – Column 11 Line 5).
In claim 25 Purus in view of Byrd discloses all of claim 23. Purus does not explicitly disclose wherein the management application is configured to apply at least one predefined policy that limits the impact of the performance profiling tool on the application based on priority levels.
Byrd teaches wherein the management application is configured to apply at least one predefined policy that limits the impact of the performance profiling tool on the application based on priority levels (Par. 81 “adjust the priorities for scheduling of the activity monitors”).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled that wherein the management application is configured to apply at least one predefined policy that limits the impact of the performance profiling tool on the application based on priority levels based on the teaching of Byrd in combination with the disclosure of Purus in order to control the impact of the monitoring as needed (Byrd Par. 81), thus leading to a more dynamic system.
In claim 26 Purus in view of Byrd discloses all of claim 25. Purus does not explicitly disclose wherein the at least one predefined policy includes different impact thresholds for applications of different priority levels.
Byrd teaches wherein the at least one predefined policy includes different impact thresholds for applications of different priority levels (Par. 75, 80-81).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled that wherein the at least one predefined policy includes different impact thresholds for applications of different priority levels based on the teaching of Byrd in combination with the disclosure of Purus in order to control the impact of the monitoring as needed (Byrd Par. 81), thus leading to a more dynamic system.
Claim(s) 5, 7, 19, and 27 are rejected under 35 U.S.C. 103 as being unpatentable over Purus in view of Byrd and in further view of Beck (WO 2005045739 A2).
In claim 5, Purus in view of Byrd discloses all of claim 1. Purus does not explicitly disclose adjusting the sampling interval includes: using machine learning to determine when to collect more or less of the performance data.
Beck teaches using machine learning to determine when to collect more or less of the performance data (Page 26 Lines 1-17 Page 30 Lines 5-15).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled that using machine learning to determine when to collect more or less of the performance data based on the teaching of Beck in combination with the combined disclosures of Purus and Byrd in order to dynamically generate manifests of selected portions of the model code based on requirements (Purus Page 30 Lines 5-15) thus leading to a more dynamic system.
In claim 7, Purus in view of Byrd discloses all of claim 2. Purus further discloses aggregating the performance data in the database (Column 2 Lines 57-67, 50-65 “composite historical performance data”, “at the bequest of the enterprise”).
Purus does not explicitly disclose aggregating the performance data in the database via a machine learning algorithm or a neural network.
Beck teaches aggregating the performance data in the database via a machine learning algorithm or a neural network (Page 30 Lines 5-15).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled that aggregating the performance data in the database via a machine learning algorithm or a neural network based on the teaching of Beck in combination with the combined disclosures of Purus and Byrd in order to dynamically generate manifests of selected portions of the model code based on requirements (Purus Page 30 Lines 5-15) thus leading to a more dynamic system.
In claim 19, Purus in view of Byrd discloses all of claim 1. Purus does not explicitly disclose Wherein the sampling interval is adjusted using machine learning to determine when to collect more or less of the performance data.
Beck teaches using machine learning to determine when to collect more or less of the performance data (Page 26 Lines 1-17 Page 30 Lines 5-15).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled that using machine learning to determine when to collect more or less of the performance data based on the teaching of Beck in combination with the combined disclosures of Purus and Byrd in order to dynamically generate manifests of selected portions of the model code based on requirements (Purus Page 30 Lines 5-15) thus leading to a more dynamic system.
In claim 27, Purus in view of Byrd discloses all of claim 21. Purus discloses wherein the at least one feedback module includes a real-time performance analysis engine (Column 10 Lines 17-27 “monitoring and analyzing real-time data and the rate”) configured to provide a recommendation regarding an application optimization (Column 9 Lines 50-65 “optimization/adjustment is dynamically”).
Purus does not explicitly disclose wherein the at least one feedback module includes a machine recommendation system configured to use machine learning to process the performance data.
Beck teaches wherein the at least one feedback module includes a machine recommendation system configured to use machine learning to process the performance data (Page 26 Lines 1-17 Page 30 Lines 5-15).
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was filled that wherein the at least one feedback module includes a real- time performance analysis engine and machine recommendation system configured to use machine learning to process the performance data and provide a recommendation regarding an application optimization based on the teaching of Beck in combination with the combined disclosures of Purus and Byrd in order to dynamically generate manifests of selected portions of the model code based on requirements (Purus Page 30 Lines 5-15) thus leading to a more dynamic system.
Response to Arguments
Applicant's arguments filed 03/19/2026 have been fully considered but they are not persuasive. Regarding applicant’s arguments directed to claim 1 on pages 8-9, the examiner respectfully disagrees. Looking at Byrd the monitors are clearly applications as can be seen in the software architecture in Fig. 6. Further Purus discloses optimizing the threshold based on the importance, i.e. “priority” of each parameter. These are both within the BRI of the current claims. As cited above, the prior art discloses/teaches the cited amended limitations.
Regarding applicant’s arguments directed to claim 15 on pages 9-10, the examiner respectfully disagrees. As cited above, the elements are taught by the prior art.
Regarding applicant’s arguments directed to claim 21 on pages 10-11, the examiner respectfully disagrees. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “feedback loop”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 8639963 B2, System And Method For Indirect Throttling Of A System Resource By A Processor; US 20120324572 A1, SYSTEMS AND METHODS THAT PERFORM APPLICATION REQUEST THROTTLING IN A DISTRIBUTED COMPUTING ENVIRONMENT;
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 BRANDON J BECKER whose telephone number is (571)431-0689. The examiner can normally be reached M-F 9:30-5:30.
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, Shelby Turner can be reached at (571) 272-6334. 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.
/B.J.B/ Examiner, Art Unit 2857
/SHELBY A TURNER/ Supervisory Patent Examiner, Art Unit 2857
Prosecution Insights