DETAILED ACTION
Status of the Application
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This communication is a non-final action in response to application filed on 10/27/2023. Claims 1-20 are currently pending and have been considered below.
Claim Rejections - 35 USC § 112
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 3-6, 10-13, 17-20 are 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.
Claims 3, 10 and 17 recite “autoscaling min, max, scale in and scale out data”. While the specification gives numeric table example of these terms, it does not properly define what these terms mean. While examiner interprets min as minimum and max as maximum; scale in and scale out are still vague and unclear. Therefore, the claims are indefinite.
Claims 4, 6, 11 and 18 are also rejected by virtue of their dependency from claims 3, 10 and 17 without remedying the deficiencies identified above.
Claims 5, 6, 12, 13, 19-20, recite “the software application behaviour”. There is no antecedent basis for this limitation in the claims. Therefore, the claims are indefinite.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. Claims 1-20 are determined to be directed to an abstract idea.
The claims 1-20 are directed to a judicial exception (i.e., law of nature, natural phenomenon, or abstract idea), without providing a practical application integration and without providing significantly more.
As per Step 1 of the subject matter eligibility analysis, Claims 1-20 are directed to a method, apparatus and product which are within the four statutory categories of invention.
As per Step 2A-Prong 1 of the subject matter eligibility analysis, Claims 1, 8, and 15 are directed specifically to the abstract idea of continuously monitoring carbon emissions for establishing software application priority for autoscaling; utilizing the carbon emissions as an observability metric while leveraging business criticality and burst capacity to define the software application execution scenario; identifying a first sustainability threshold for the software application and a second sustainability threshold for each of a plurality of business units leveraging a carbon footprint based on the business criticality and strategic importance for a plurality of software applications including the software application in an enterprise application portfolio; and autoscaling the software application execution based on the first sustainability threshold and the second sustainability threshold; which include mental processes (observing and evaluating data related to software usage and related carbon emissions for a judgement or opinion on scaling/adjusting the software usage/execution), and certain methods of organizing human activity based on fundamental economic practice (managing software usage in a business environment), and managing personal behavior and interactions between people (following rules and instructions to manage software usage in a business environment). Claims 2-7, 9-14, and 16-20 are directed to the abstract idea of claim 1, 8, or 15 with further details on the parameters/attributes of the abstract idea which includes mental processes and certain methods of organizing human activity for similar reasons as provided above for claim 1, 8, or 15. After considering all claim elements, both individually and in combination and in ordered combination, it has been determined that the claims do not amount to significantly more than the abstract idea itself.
As per Step 2A-Prong 2 of the subject matter eligibility analysis, while the claims 1-20 recite additional limitations which are hardware or software elements, such as a computing device, auto/automatically (i.e., using a computer or processor), application programming interfaces (APIs) from virtual server system, computer program product for autoscaling a software application based on carbon emissions, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processor to…, apparatus comprising: a memory configured to store instructions; and a processor configured to execute the instructions to…; these limitations are not enough to qualify as a practical application being recited in the claims along with the abstract idea since these elements are merely invoked as a tool to apply instructions of an abstract idea in a particular technological environment, and mere application of an abstract idea in a particular technological environment and merely limiting the use of an abstract idea to a particular technological field do not integrate an abstract idea into a practical application (MPEP 2106.05(f)&(h)). The claims do not amount to "practical application" for the abstract idea because they neither (1) recite any improvements to another technology or technical field; (2) recite any improvements to the functioning of the computer itself; (3) apply the judicial exception with, or by use of, a particular machine; (4) effect a transformation or reduction of a particular article to a different state or thing; (5) provide other meaningful limitations beyond generally linking the use of the judicial exception to a particular technological environment.
As per Step 2B of the subject matter eligibility analysis, while the claims 1-20 recite additional limitations which are hardware or software elements, such as a computing device, auto/automatically (i.e., using a computer or processor), application programming interfaces (APIs) from virtual server system, computer program product for autoscaling a software application based on carbon emissions, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processor to…, apparatus comprising: a memory configured to store instructions; and a processor configured to execute the instructions to…; these limitations are not enough to qualify as “significantly more” being recited in the claims along with the abstract idea since these elements are merely invoked as a tool to apply instructions of an abstract idea in a particular technological environment, and mere application of an abstract idea in a particular technological environment and merely limiting the use of an abstract idea to a particular technological field do provide significantly more to an abstract idea (MPEP 2106.05 (f) & (h)). The claims do not amount to "significantly more" than the abstract idea because they neither (1) recite any improvements to another technology or technical field; (2) recite any improvements to the functioning of the computer itself; (3) apply the judicial exception with, or by use of, a particular machine; (4) effect a transformation or reduction of a particular article to a different state or thing; (5) add a specific limitation other than what is well-understood, routine and conventional in the field; (6) add unconventional steps that confine the claim to a particular useful application; nor (7) provide other meaningful limitations beyond generally linking the use of the judicial exception to a particular technological environment.
Therefore, since there are no limitations in the claims 1-20 that transform the exception into a patent eligible application such that the claims amount to significantly more than the exception itself, and looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually, the claims are rejected under 35 USC § 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Aurongzeb et al (US 20240037684 A1) in view of Pillai et al (US 10936473 B2).
As per Claim 1, Aurongzeb teaches a method (Abstract, claim 8) comprising:
continuously monitoring, by a computing device, carbon emissions for establishing software application priority for autoscaling (para. 0044, “the client device CO2 emission tracking system 250 in an embodiment may gather data regarding hardware configuration and power consumption from the power analytics module 240 and data regarding software performance and processor/memory usage from the application analytics module 230 during routine monitoring periods. For example, such a monitoring period may be set to occur at a frequency having a default value (e.g., one hour, one day, one week), or may be set by the user of the first client information handling system 200 via the graphical user interface (GUI) 290. The client device CO2 emissions tracking system 250 in an embodiment may determine CO2 emissions generated due to software application usage and power usage at the client information handling system 200 for each of such monitoring periods, as described in greater detail below with respect to FIG. 4.”; 0048, “For example, a software application may utilize a proportion of total network interface device resources, processing resources, memory resources, or display resources. The CO2 emission tracking system 250 in an embodiment may also determine an application CO2 emissions value for a given software application by multiplying one or more of these power CO2 emissions values for a specific hardware component by the percentage of hardware component resources consumed during execution of a software application. For example, in an embodiment in which a gaming software application is consuming 90% of GPU resources, 90% of display resources, 25% of network interface device resources, and 10% of memory resources, the CO2 emission tracking system 250 may determine an application CO2 emissions value for the gaming application specifically by summing 90% of the power CO2 emissions value for the GPU, 90% of the power CO2 emissions value for the display, 25% of the power CO2 emissions value for the network interface device, and 10% of the power CO2 emissions value for the memory.”; note that continuously monitoring herein is interpreted as collecting data to cover a continuous time interval and not necessarily collecting data nonstop in realtime; accordingly para. 0044, monitors for continuos time periods such as one hour, one day, one week; para. 0068 monitoring period set to every 15 minutes);
utilizing the carbon emissions as an observability metric while leveraging business criticality and burst capacity to define the software application execution scenario (para. 0039, regarding no software app will pass 85% (i.e., burst cap) usage of any resource capacity; para. 0067, “The GUI 290 in an embodiment may display a recommendation to terminate the problematic [i.e., criticality] software application or to limit hardware or network resources made available during execution of the problematic software application. For example, the GUI 290 may display a recommendation to terminate any background applications identified as problematic software applications. As another example, the GUI 290 in an embodiment in which the client device CO2 emissions tracking system 250 identified the gaming application as a problematic software application for consuming more than 85% of the processor resources may recommend limiting the gaming application's access to processor resources to 85%. In yet another example, the GUI 290 in an embodiment in which the client device CO2 emissions tracking system 250 identified the streaming video application as a problematic software application for consuming more than 85% of the memory resources may recommend limiting the streaming video application's access to memory resources to 85%. As yet another example, the GUI 290 in an embodiment in which the client device CO2 emissions tracking system 250 identified the videoconferencing software application as a problematic software application for consuming more than 85% of the network interface device resources may recommend limiting the videoconferencing software application's access to processor resources to 85%. In still another example, the GUI 290 in an embodiment in which the client device CO2 emissions tracking system 250 identified the streaming video application as a problematic software application for consuming more than 85% of the display resources may recommend limiting the streaming video application's access to display resources to 85%.”; also see fig. 3 and para. 0069-0070);
identifying a first sustainability threshold for the software application and a second sustainability threshold for each of a plurality of business units leveraging a carbon footprint based on the business criticality and strategic importance for a plurality of software applications including the software application in an enterprise application portfolio (para. 0039, “For example, the processor 242 may be associated with a maximum processor resource threshold value of 85%, indicating that no software application currently executing at the first information handling system 200 should be consuming more than 85% of the processor's 242 resources (e.g., as measured by a percentage of total calls made to that processor 242). As another example, the memory 246 may be associated with a maximum memory resource threshold value of 85%, indicating that no software application currently executing at the first information handling system 200 should be consuming more than 85% of the memory's 246 resources (e.g., as measured by a percentage of total bytes of data stored at the memory 246). In yet another example, the network interface device 220 may be associated with a maximum network interface device resource threshold value of 85%, indicating that no software application currently executing at the first information handling system 200 should be consuming more than 85% of the network interface device's 220 resources (e.g., as measured by a percentage of total throughput transceived by the network interface device 220). In still another example, the display 245a may be associated with a maximum display resource threshold value of 85%, indicating that no software application currently executing at the first information handling system 200 should be consuming more than 85% of the display's 245a resources (e.g., as measured by a percentage of active screen time used in the display of the specific software application's GUI via the display 245a).”; 0061-0065, regarding comparing CO2 emissions for software applications to benchmarks or averages to identify spikes and “The significance in difference between the current application CO2 emissions value(s) and the current application benchmark CO2 emissions value(s), the previous application CO2 emissions value(s), or the average application CO2 emissions value(s) (determined as described directly above) may be gauged according to a preset usage warning threshold value. Such a preset usage warning threshold value may be used to identify unexpected spikes in resource usage by one or more software applications in an embodiment. For example, the preset warning threshold may be when a current application CO2 emissions value exceeds a deviation threshold in an embodiment. The preset usage warning threshold value in an embodiment may apply to the overall current application CO2 emissions value (e.g., not segregated by specific applications), or may apply on an application-by-application basis. For example, the preset usage warning threshold value may be set to 20%, indicating that an adjustment to the usage of software applications may be appropriate when the current application CO2 emissions value differs from the previous application CO2 emissions value by 20% or more. This is only one example of a preset usage warning threshold value, and any other factors or percentages are also contemplated. This may be used to identify one or more problematic software applications in an embodiment.”; also see para. 0066 regarding plurality of software apps CO2 emissions compared to preset thresholds to identify problematic apps);
scaling the software application execution based on the first sustainability threshold and the second sustainability threshold (para. 0067, “The GUI 290 in an embodiment may display a recommendation to terminate the problematic software application or to limit hardware or network resources made available during execution of the problematic software application. For example, the GUI 290 may display a recommendation to terminate any background applications identified as problematic software applications. As another example, the GUI 290 in an embodiment in which the client device CO2 emissions tracking system 250 identified the gaming application as a problematic software application for consuming more than 85% of the processor resources may recommend limiting the gaming application's access to processor resources to 85%. In yet another example, the GUI 290 in an embodiment in which the client device CO2 emissions tracking system 250 identified the streaming video application as a problematic software application for consuming more than 85% of the memory resources may recommend limiting the streaming video application's access to memory resources to 85%. As yet another example, the GUI 290 in an embodiment in which the client device CO2 emissions tracking system 250 identified the videoconferencing software application as a problematic software application for consuming more than 85% of the network interface device resources may recommend limiting the videoconferencing software application's access to processor resources to 85%. In still another example, the GUI 290 in an embodiment in which the client device CO2 emissions tracking system 250 identified the streaming video application as a problematic software application for consuming more than 85% of the display resources may recommend limiting the streaming video application's access to display resources to 85%.”).
Aurongzeb does not teach automatically scaling; however Pillai teaches autoscaling the software application execution based on the sustainability measures (Col. 6 12-21, “The method might also comprise tuning the software application, such that power consumption of the one or more hardware components matches a power load caused by execution of the software application, based at least in part on the power consumption profile for the software application. In some instances, tuning might be performed automatically by the computer, based at least in part on the power consumption profile for the software application.”).
It would be obvious for an ordinary skill, before the earliest filing date of the invention, to modify Aurongzeb with aforementioned teachings of Pillai, in the field of sustainable software execution, with the motivation to timely and without human involvement and delay to automatically make software adjustment for improved sustainability metrics.
As per Claim 2, Aurongzeb in view of Pillai teaches a method as recited above for Claim 1. Aurongzeb further teaches identifying a sustainability index for each application of the plurality of software applications (Fig. 3,
PNG
media_image1.png
568
754
media_image1.png
Greyscale
Para. 0069-0070).
As per Claim 3, Aurongzeb in view of Pillai teaches a method as recited above for Claim 1. Aurongzeb further teaches generating an application threshold scale leveraging an autoscaling min, max, scale in and scale out data (0067, “to terminate the problematic software application or to limit hardware or network resources made available during execution of the problematic software application.” i.e., min, scale in/out and “limiting the gaming application's access to processor resources to 85%” i.e., max).
As per Claim 4, Aurongzeb in view of Pillai teaches a method as recited above for Claim 3. Aurongzeb further teaches establishing an application threshold burst level (ATL) for the plurality of software applications (0039, “For example, the processor 242 may be associated with a maximum processor resource threshold value of 85%, indicating that no software application currently executing at the first information handling system 200 should be consuming more than 85% [i.e., burst level] of the processor's 242 resources (e.g., as measured by a percentage of total calls made to that processor 242). As another example, the memory 246 may be associated with a maximum memory resource threshold value of 85%, indicating that no software application currently executing at the first information handling system 200 should be consuming more than 85% of the memory's 246 resources (e.g., as measured by a percentage of total bytes of data stored at the memory 246). In yet another example, the network interface device 220 may be associated with a maximum network interface device resource threshold value of 85%, indicating that no software application currently executing at the first information handling system 200 should be consuming more than 85% of the network interface device's 220 resources (e.g., as measured by a percentage of total throughput transceived by the network interface device 220). In still another example, the display 245a may be associated with a maximum display resource threshold value of 85%, indicating that no software application currently executing at the first information handling system 200 should be consuming more than 85% of the display's 245a resources (e.g., as measured by a percentage of active screen time used in the display of the specific software application's GUI via the display 245a).”).
As per Claim 5, Aurongzeb in view of Pillai teaches a method as recited above for Claim 1. Pillai further teaches wherein the observability metric is utilized within code of the software application for altering the software application behavior (Col. 6 12-21, “The method might also comprise tuning the software application, such that power consumption of the one or more hardware components matches a power load caused by execution of the software application, based at least in part on the power consumption profile for the software application. In some instances, tuning might be performed automatically by the computer, based at least in part on the power consumption profile for the software application.”; Col. 19 61-67, “For example, the green software application might be tuned or designed to quickly release resources, contain efficient computational logic, minimize or eliminate large and/or long-lived objects in memory, minimize storage of large chunks of data, reduce heavy data transfer over the network, and/or closely match hardware and software characteristics, or the like”-note that one or more of these changes during tuning would require software code update.).
It would be obvious for an ordinary skill, before the earliest filing date of the invention, to modify Aurongzeb with aforementioned teachings of Pillai, in the field of sustainable software execution, with the motivation to timely and without human involvement and delay to automatically make software adjustment for improved sustainability metrics.
As per Claim 6, Aurongzeb in view of Pillai teaches a method as recited above for Claim 4. Aurongzeb further teaches wherein the alteration of the software application behavior is performed using the autoscaling based on the carbon emissions (para. 0067, “The GUI 290 in an embodiment may display a recommendation to terminate the problematic software application or to limit hardware or network resources made available during execution of the problematic software application. For example, the GUI 290 may display a recommendation to terminate any background applications identified as problematic software applications. As another example, the GUI 290 in an embodiment in which the client device CO2 emissions tracking system 250 identified the gaming application as a problematic software application for consuming more than 85% of the processor resources may recommend limiting the gaming application's access to processor resources to 85%. In yet another example, the GUI 290 in an embodiment in which the client device CO2 emissions tracking system 250 identified the streaming video application as a problematic software application for consuming more than 85% of the memory resources may recommend limiting the streaming video application's access to memory resources to 85%. As yet another example, the GUI 290 in an embodiment in which the client device CO2 emissions tracking system 250 identified the videoconferencing software application as a problematic software application for consuming more than 85% of the network interface device resources may recommend limiting the videoconferencing software application's access to processor resources to 85%. In still another example, the GUI 290 in an embodiment in which the client device CO2 emissions tracking system 250 identified the streaming video application as a problematic software application for consuming more than 85% of the display resources may recommend limiting the streaming video application's access to display resources to 85%.”).
As per Claim 7, Aurongzeb in view of Pillai teaches a method as recited above for Claim 1. Aurongzeb further teaches wherein continuously monitoring the carbon emissions utilizes application programming interfaces (APIs) from virtual server system providers for monitoring the emissions for each software application of the plurality of software applications (para. 0026, “The present disclosure contemplates a computer-readable medium that includes instructions, parameters, and profiles 154 or receives and executes instructions, parameters, and profiles 154 responsive to a propagated signal, so that a device connected to a network 121 may communicate voice, video or data over the network 121. Further, the instructions 154 may be transmitted or received over the network 121 via the network interface device 120. The information handling system 100 may include a set of instructions 154 that may be executed to cause the computer system to perform any one or more of the methods or computer-based functions disclosed herein, such as determining an amount of greenhouse gas emissions that may be attributable to usage at an information handling system of software applications and power, tracking such greenhouse gas emissions over time, and making recommendations for application usage that may reduce such emissions. For example, instructions 154 may include a particular example of a client device CO2 emission tracking system 150, or other aspects or components. Various software modules comprising application instructions 154 may be coordinated by an operating system (OS), and/or via an application programming interface (API). An example operating system may include Windows®, Android®, and other OS types. Example APIs may include Win 32, Core Java API, or Android APIs. Application instructions 154 may also include any application processing drivers, or the like executing on information handling system 100.”).
As per claims 8-14, claims 8-14 recite substantially similar limitations as claim 1-7, respectively; therefore, claims 8-14 are rejected with the same reasoning, rationale and motivation as recited above for claims 1-7, respectively.
As per claim 8, Aurongzeb further teaches computer program product, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions executable by a processor to cause the processor to… (para. 0026-0029).
As per claims 15-19, 20, claims 15-19, 20 recite substantially similar limitations as claim 1-5, 6+7, respectively; therefore, claims 15-19, 20 are rejected with the same reasoning, rationale and motivation as recited above for claims 1-5, 6+7, respectively.
As per claim 15, Aurongzeb further teaches apparatus comprising: a memory configured to store instructions; and a processor configured to execute the instructions to… (para. 0026-0029).
Conclusion
Additional relevant art not relied upon includes:
Makofsky et al (US 20250005595 A1), regarding “Additionally, the GHG emissions estimation system 10 may provide indications of infrastructural components and/or operational parameters of the application(s) that are the largest contributors to the estimated GHG emissions or recommendations for lowering the estimated GHG emissions, enabling the IAC files and/or source code of the application(s) to be modified to reduce the estimated GHG emissions prior to deployment.”
Vinay et al (EP 4530963 A1), regarding “A computer system and method for optimizing carbon footprint associated with a software application is disclosed. The method comprises detecting, by a processor (104) an event associated with a software application. The event is indicative of a need for optimizing carbon footprint associated with a task to be performed on the software application. Further, a set of control parameters affecting the carbon footprint and a performance metric associated with the software application are identified. The set of control parameters identified, is further optimized using a predetermined solver. The optimized set of control parameters correspond to optimized carbon footprint associated with the software application. Furthermore, a notification indicative of an outcome of optimizing the set of control parameters is generated on a display device (114).”
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MEHMET YESILDAG whose telephone number is (571)272-3257. The examiner can normally be reached M-F 8:30 am - 5:00 pm.
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, Jerry O'Connor can be reached on (571) 272-6787. 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.
Sincerely,
/MEHMET YESILDAG/Primary Examiner, Art Unit 3624
Prosecution Insights