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
This action is in response to the amendment filed on 7/15/2026. Claims 1-20 are pending. Claims 1, 7, 8, 10, 16, 17, 19 are amended. No claims have been added. No claims have been cancelled.
Response to Arguments
Applicant’s arguments, see page 11-12 filed 7/15/2026, with respect to the rejection(s) of claim(s) 1-20 under 102/103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, after an updated search an updated rejection is made in view of applicant’s amendments.
Applicant's arguments filed 7/15/2026 have been fully considered but they are not persuasive. The applicant has argued the 101 rejection. The applicant has argued “Here, as amended, the independent claims recite application programming interface ("API") processing techniques that are implemented to facilitate the ROI determination. See, e.g., Applicants' Specification at [0023]-[0024] (describing API-based execution of request determination.) Moreover, the claims recite determining drift metric representing a likelihood of variation between separate executions of the manual software development task determined based on the set of manual metrics and a devices affected metric, and a network risk profile based at least in part on the devices affected metric. Such operations are not practically capable of being performed in the human mind at least because they require execution of network- specific operations including API-based executions and analysis of device configurations.” The examiner respectfully disagrees. First, the applicant has only amended the term API into claim 1, therefore the argument does not apply to claims 10 and 19 or their dependents. The limitation of an API is evaluated below in the updated 101 rejection. The API is identified as an additional element. A claim that recites a mental process still recites a judicial exception even when it also recites additional computer elements, or performs the mental process on in a computer environment. The question is whether or not the claim recites a mental process not whether every limitation is mental. The API recited in claim 1 does not contribute any specific to the claimed analysis. The claim uses an API only to receive a request. How the drift metric, stability score, criticality score, or network risk profile is determined does not depend on it in any way. The claims also do not recite an analysis “of device configurations.” The claims recite a devices affected metric.” Under the broadest reasonable interpretation in view of the specification the metric is a count of the number of devices touched by the automation software during execution (¶ 37-38), the job inventory indicated the number of devices touched. Nothing in the claims requires inspecting, comparing, or analyzing the configuration of any device. Further, the limitations that the applicant relies on are observations, evaluations, and judgements that can practically be performed in the human mind or with pen and paper. The claims recite only the results of determinations. They do include a formula, algorithm, or technique for reaching them. A person can review records of how a task has been performed on different occasion and judge how likely it is to be performed inconsistently. The applicant does not identify any limitation requiring a volume of data, speed, or number of devices beyond human capacity. Even if the claimed determinations were performed faster or at larger scale by a computer, using a computer to perform a mental process more quickly or efficiently does not take the claim out of the mental process grouping.
The applicant has argued “Here, mere generation of a set of comparison metrics, at most, involves a mathematical concept. However, no mathematical concept itself is recited in the claims. That is, unlike the above examples where explicit equations and mathematical relationships were recited in the claims, here the claims recite a series of functional, technological steps to evaluate computing infrastructure health-specifically, monitoring device inventories, computing configuration drift, and establishing technological criticality scores to compile a risk profile. The absence of any explicit mathematical formulas, equations, or purely mathematical algorithms confirms that the claims are directed to a tangible network-monitoring methodology rather than an abstract mathematical concept. For at least these reasons, Applicant respectfully submits that the claims do not recite an abstract idea under Step 2A, Prong One, and requests withdrawal of the rejection under 35 U.S.C. § 101.” The examiner respectfully disagrees. A mathematical calculation need not be expressed as a formula or in mathematical symbols. A claim need not recite the word calculating to recite a mathematical calculation. The claims recite determining a drift metric, generating comparison metrics, and determining a stability score. These limitations do not merely involve or rely on mathematics in the background. The claimed result of each step is itself a computed numerical value. The claims therefore recite a mathematical calculation, the absence of an explicit equation does not change that conclusion.
The applicant has argued “The present claims are not analogous to any of the above cases exemplifying claims directed to fundamental economic practices. The claims do not recite mitigating risk, executing transactions, financial instruments, advertising or any other form of economic practice. Rather, the claims recite a framework for determining the computing and structural efficiencies of tool automation software within a software development workflow. Such operations do not recite fundamental economic practices. Rather, they stop short of any commercial transaction, contract formation, or financial market interaction, and instead focus on the inner architectural performance and configuration stability of a computing network. Moreover, the claims, as amended, recite:…Such operations illustrate that the claims recite operations for identifying configuration drift, assessing hardware impact across a network, and evaluating computational risks within software deployment pipelines, rather than generating and evaluating financial values. Moreover, analyzing claim eligibility based on what recited operations allow for impermissibly broadens the scope of the "certain" methods of organizing human activity. That is, determining various metrics related to an automated process does not transform a network stability tool into a fundamental economic practice, because the core claimed limitations instead relate to network hardware performance, software task variances, and specific device configuration metrics. Therefore, the claims do not recite a patent ineligible method of organizing human activity. For at least these reasons, Applicant respectfully submits that the claims do not recite an abstract idea under Step 2A, Prong One, and requests withdrawal of the rejection under 35 U.S.C. § 101.” The applicant’s arguments, have been fully considered and are persuasive. Upon further consideration, and in view of the amendments, the examiner no longer relies on the certain methods of organizing human activity grouping for independent claims 1, 10, 19. Although the certain methods of organizing human activities grouping has been removed for the claims, as amended the independent claims recite an abstract idea under the mental-process and mathematical concept groupings.
The applicant has argued “Here, like those eligible claims in DDR, BASCOM, and particularly Amdocs, the claims recite technical improvements to network data management by reciting particular rules for assessing network stability, particularly in a manner that can automatically control network operations (e.g., as in claim 7 as amended). Applicant's specification notes that "the tracking system can... monitor and analyze improvements to infrastructural stability, improving risk profiles across multiple areas and services within a computing network. By monitoring stability (e.g., drift) across separate executions of manual tasks, and identifying the risks of instability for the manual task" the tracking system can provide improvements to network stability" Applicant's Specification at [0055]. Such techniques for detecting, assessing, and controlling drift, can address the issues of drift, referring to gradual changes in network performance, behavior and structure, which "can degrade network performance, such as by increasing latency, and by resulting in configuration inconsistencies across a network." Id. at [0070].” The examiner respectfully disagrees. An improvement to the functioning of a computer or other technology must be reflected in the claim itself, not merely described in the specification. The claim must include the components or steps of the invention that provide the improvement described in the specification. The specification ties the asserted improvement in network stability to implementing automation software that reduces drift. It describes the ROI service “automatically implementing the automation software to reduce the identified network instability.” And the drift “identifying and implementing software for automation based on network stability scores.” As claimed the independent claims do not specifically implement anything. They receive metrics, determine a drift metric, a stability score, a criticality score, and a network risk profile, and then output those values. Nothing in the independent claims changes, configures, or controls the network. The network is only the subject of the analysis. Collecting information about a technological system, analyzing it, and reporting the results, without more, does not improve that system, even when the information concerns the system’s performance or stability. The specifications statement in ¶ 56 that monitoring drift “provide technical improvements to network stability” is an assertion without explaining how computing and outputting the claimed scores improves the network itself. To the extent the claimed metrics produce a better assessment of risk would be an improvement in the abstract idea itself, not an improvement in computer or network technology.
The applicant has argued “The recited operations, evaluated as a whole, achieve these technical benefits. The independent claims recite a process for determining a network risk profile based on multiple metrics analyzed at a device and software-task level. Such metrics include drift metrics, where identifying drift is achieved by tracking separate executions of software tasks across devices via a devices-affected metric. The claims thus recite a specific set of rules that enable network stability monitoring in an unconventional, non-routine manner. For at least these reasons, the independent claims recite a technological solution (via generating a set of comparison metrics including a drift metric determined based on manual metrics and a devices affected metric, and determining a network risk profile based on a network stability score and a criticality score) to a technological problem (operational drift caused by inconsistent manual execution of software tasks that leads to increased network latency and configuration inconsistencies across a network) via an unconventional arrangement of operations. Therefore, the claims are patent eligible under Step 2A, Prong Two, and Step 2B of the Patent Eligibility Guidance. Based on the foregoing, Applicant respectfully requests withdrawal of the rejections under 35 U.S.C. § 101 of all pending claims.” The examiner respectfully disagrees. Specifically, the claims do not recite the operations the applicant describes. The applicant states that “where identifying drift is achieved by tracking separate executions of software tasks across devices via a devices-affected metric.” The claims do not recite tracking. They recite that the drift metric is “determined based on the set of manual metrics and devices affected metric.” The claims do not require monitoring any execution of the manual task, observing any device, or associating any execution with any device. The devices affected metric is a count of devices touched by the automation software. A drift metric based on a count, together with previously received manual metrics does not track executions across devices. The claimed operations do not address network latency or configuration inconsistency. The independent claims estimate a likelihood that a task is performed inconsistently, score its stability and criticality, combine those scores into a risk profile, and output the results. Nothing in the independent claims reduces latency, corrects any configuration, or changes how the network operates. Identifying and reporting risk is not a technological solution to the condition that creates it. The operations the Applicant identifies as unconventional are generating comparison metrics including a drift metric, and determining a network risk profile from a stability score and a criticality score. These are the limitations that are identified as abstract under step 2A, Prong One. The independent claims are cite an abstract idea, do not integrate that idea into a practical application, and do not recite significantly more under step 2B. The previous 101 rejection is maintained and updated below.
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 USC 101 because the claimed invention is directed to a judicial exception (i.e. abstract idea) without anything significantly more.
Step 1: Claims 1-9 are directed to a method, claims 10-18 are directed to a system, and claims 19-20 are directed to a non-transitory computer readable medium. Therefore, claims 1-20 are directed to patent eligible categories of invention.
Step 2A, Prong 1:
The claim(s) recite(s) (mathematical relationships/formulas, mental process or certain methods of organizing human activity). Specifically the independent claims recite:
mental process: as drafted, the claim recites the limitations of receiving manual metrics for a manual task, receiving a request to execute automation software, generating automation metrics, generating comparison metrics, determining a network risk profile, determining scores, generating a network risk profile, and outputting the comparison metrics which is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting “one or more processors,” or “software,” nothing in the claim precludes the determining step from practically being performed in the human mind. For example, but for the “processor” language, the claim encompasses a user manually generating comparison metrics. The mere nominal recitation of a generic appliances does not take the claim limitation out of the mental processes grouping. This limitation is a mental process.
mathematical formula: The claim recites a mathematical concept, and in this generating a set of comparison metrics, determining a stability score, and generating a criticality score. Thus, the claim recites mathematical relationships. This category includes mathematical relationships (relationships between numbers or variables), formulas (using symbols or text/words), and calculations (including "determining a value" claim elements). A mathematical relationship is a relationship between variables or numbers. A mathematical relationship may be expressed in words or using mathematical symbols. For example, pressure (p) can be described as the ratio between the magnitude of the normal force (F) and area of the surface on contact (A), or it can be set forth in the form of an equation such as p = F/A. Examples of mathematical relationships recited in a claim include: a relationship between reaction rate and temperature, which relationship can be expressed in the form of a formula called the Arrhenius equation, Diamond v. Diehr; a conversion between binary-coded decimal and pure binary numerals, Gottschalk v. Benson; and a mathematical relationship between enhanced directional radio activity and antenna conductor arrangement (i.e., the length of the conductors with respect to the operating wave length and the angle between the conductors), Mackay Radio & Tel. Co. v. Radio Corp. of Am.
Dependent claims 2-4, 9, 11-13, 18, 20 further narrow the abstract idea identified in the independent claims and do not introduce further additional elements for consideration.
Dependent claims 5-8, 14-17, will be evaluated under Step 2A, Prong 2 below.
Step 2A, Prong 2: Independent claims 1, 10 and 19 do not integrate the judicial exception into a practical application. Claim 1 is a method comprising “software development… an application programming interface (‘API’) call to execute an automation software... a network, the network coupled to the automation software.” Claim 10 is a system comprising “software development…one or more processors configured to… automation software… a network, the network coupled to the automation software.” Claim 19 is “A non-transitory computer readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to… software development task… automation software… a network, the network coupled to the automation software.” These additional elements are mere instructions to implement an abstract idea using a computer in its ordinary capacity, or merely uses the computer as a tool to perform the identified abstract idea. Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, generate, and output data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity, using a mathematical relationship) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f).
Therefore, the additional elements of the independent claims, when considered both individually and in combination, are not sufficient to prove integration into a practical application.
Dependent claims 2-4, 9, 11-13, 18, 20 further narrow the abstract idea identified in the independent claims and do not introduce further additional elements for consideration, which does not integrate the judicial exception into a practical application.
Dependent claims 5, 14, introduce the additional element of “wherein the set of automation metrics includes a success rate score, an automation length metric and an automation configuration.” This limitation does not integrate the judicial exception into a practical application because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claims 6, 15, introduce the additional element of “wherein outputting the set of comparison metrics comprises: receiving a request to display the set of comparison metrics and a user configuration associated with the request; based on the request and the user configuration associated with the request: displaying, via a first display interface, a first subset of the set of comparison metrics including an hours saved metric included within the set of comparison metrics; or displaying, via a second display interface, a second subset of the set of comparison metrics including a stability score of a network.” This limitation provides nothing more than mere instructions to implement an abstract idea on a generic computer. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception. Therefore, this limitation is not sufficient to prove integration into a practical application.
Dependent claims 7, 16, introduce the additional element of “responsive to the network risk profile exceeding a threshold risk score representing network instability, automatically implementing the automation software to reduce the network instability.” This limitation provides nothing more than mere instructions to implement an abstract idea on a generic computer. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception. Therefore, this limitation is not sufficient to prove integration into a practical application.
Dependent claims 8, 17 introduces the additional element of “wherein outputting the set of comparison metrics and the network risk profile comprises: identifying, based on user credentials, a first set of users and a second set of users separately requesting access to the comparison metrics: outputting, to the first set of users, the comparison metrics and the network risk profile; and outputting, to the second set of users, the comparison metrics and restricting access to the network risk profile.” This limitation provides nothing more than mere instructions to implement an abstract idea on a generic computer. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception. Therefore, this limitation is not sufficient to prove integration into a practical application.
Therefore, the additional elements of the dependent claims, when considered both individually and in the context of the independent claims, are not sufficient to prove integration into a practical application.
Step 2B: Independent claims 1, 10, and 19 do not comprise anything significantly more than the judicial exception. As can be seen above with respect to Step 2A, Prong 2, Claim 1 is a method comprising “software development… an application programming interface (‘API’) call to execute an automation software... a network, the network coupled to the automation software.” Claim 10 is a system comprising “software development…one or more processors configured to… automation software… a network, the network coupled to the automation software.” Claim 19 is “A non-transitory computer readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to… software development task… automation software… a network, the network coupled to the automation software.” These additional elements are mere instructions to implement an abstract idea using a computer in its ordinary capacity, or merely uses the computer as a tool to perform the identified abstract idea. Use of a computer or other machinery in its ordinary capacity for performing the steps of the abstract idea or other tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., certain methods of organizing human activity) is not anything significantly more than the judicial exception. See MPEP 2106.05(f).
The additional elements of the independent claims, when considered both individually and in combination, do not comprise anything significantly more than the judicial exception.
Dependent claims 2-4, 9, 11-13, 18, 20 further narrow the abstract idea identified in the independent claims and do not introduce further additional elements for consideration, which is not anything significantly more than the judicial exception.
Dependent claims 5, 14, introduce the additional element of “wherein the set of automation metrics includes a success rate score, an automation length metric and an automation configuration.” This limitation is not anything significantly more than the judicial exception because it is nothing more than generally linking the use of the judicial exception to a particular technological environment. See MPEP 2106.05(h).
Dependent claims 6, 15, introduce the additional element of “wherein outputting the set of comparison metrics comprises: receiving a request to display the set of comparison metrics and a user configuration associated with the request; based on the request and the user configuration associated with the request: displaying, via a first display interface, a first subset of the set of comparison metrics including an hours saved metric included within the set of comparison metrics; or displaying, via a second display interface, a second subset of the set of comparison metrics including a stability score of a network.” This limitation provides nothing more than mere instructions to implement an abstract idea on a generic computer. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception. Therefore, this limitation is not anything significantly more than the judicial exception.
Dependent claims 7, 16, introduce the additional element of “responsive to the network risk profile exceeding a threshold risk score representing network instability, automatically implementing the automation software to reduce the network instability.” This limitation provides nothing more than mere instructions to implement an abstract idea on a generic computer. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception. Therefore, this limitation is not anything significantly more than the judicial exception.
Dependent claims 8, 17 introduces the additional element of “wherein outputting the set of comparison metrics and the network risk profile comprises :identifying, based on user credentials, a first set of users and a second set of users separately requesting access to the comparison metrics :outputting, to the first set of users, the comparison metrics and the network risk profile; and outputting, to the second set of users, the comparison metrics and restricting access to the network risk profile.” This limitation provides nothing more than mere instructions to implement an abstract idea on a generic computer. See MPEP 2106.05(f). MPEP 2106.05(f) provides the following considerations for determining whether a claim simply recites a judicial exception with the words “apply it” (or an equivalent), such as mere instructions to implement an abstract idea on a computer: (1) whether the claim recites only the idea of a solution or outcome i.e., the claim fails to recite details of how a solution to a problem is accomplished; (2) whether the claim invokes computers or other machinery merely as a tool to perform an existing process; and (3) the particularity or generality of the application of the judicial exception. Therefore, this limitation is not anything significantly more than the judicial exception.
The additional elements of the dependent claims, when considered both individually and in the context of the independent claims, are not anything significantly more than the judicial exception.
Therefore based on the above analysis as conducted based on MPEP 2106 from the United States Patent and Trademark Office the claims are viewed as a court recognized abstract idea, are viewed as a judicial exception, does not integrate the claims into a practical application, does not provide significantly more, and does not provide an inventive concept, therefore the claims are ineligible. Accordingly, claims 1-20 are rejected under 35 USC 101.
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 1-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. The applicant has amended claims 1, 10, 19, to include the term “a manual software development task” and a drift metric representing a likelihood of variation between “the manual software development task” and a network coupled to “the manual software development task.” Although the applicant has support in the originally filed disclosure for “development information including developer teams creating the automation along with developer contact information,” the passage identifies teams that develop the automation. This is not the same as a manual task being evaluated for automation as a software development task. The original disclosure describes a generic manual task and discloses network configuration tasks as its only examples. It does not reasonably convey that the applicant possessed the narrower subgenus of manual software development tasks now claimed. Claims 8 and 17 were amended to include the language of “the comparison metrics and restricting access to the network risk profile.” The originally field disclosure has support for the drift metric in the subset withheld from users lacking technical credentials. There is no support for providing a set of users with the comparison metrics, including the drift metric, while withholding only the network risk profile.
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 1-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.
Regarding claims 1, 10, 19, the phrase "a devices affected metric" twice in the claims. This renders the claim indefinite because it is unclear whether the second recitation refers to the devices affected metric recited earlier or introduces a different devices affected metric. For purposes of examination, both recitations are interested as referring to the same metric.
Regarding claims 6, 15, the claims include “a stability score of a network.” Claims 1 and 10 already recite the term a stability score of a network. It is unclear whether claims 6 and 15 refer to the same stability score and network or introduces a new one.
The dependent claims inherit the rejections of the claim from which they depend.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 3, 6, 7, 10, 12, 15, 16, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hirpara et al. (US 20180046966 A1) in view of Vasseur et al. (US 20240323096 A1) in view of Kim (US 20180181377 A1).
Regarding claim 1, Hirpara teaches a method comprising: receiving a set of manual metrics corresponding to execution of a manual task (¶ 87-93, 98, 105, discloses calculating the cost of manual operations. ¶ 9-11, 54, 47);
receiving a request ….to execute an automation software (¶ 9-11, 51-54, discloses a request and executing on automation software. ¶ 46, 56-58, 103);
generating a set of automation metrics corresponding to an execution of the automation software (¶ 48-49, discloses the cost of automated operations. ¶ 96-98, discloses the cost of automated solutions. ¶ 9-11, 103-105, 114, 126);
generating a set of comparison metrics based on comparing the set of manual metrics with the set of automation metrics (¶ 49-52, discloses the difference between the manual and automation costs. ¶ 9-11, 85, 99-102, 109, 125-126, 139);
and outputting the set of comparison metrics (Fig. 4, 5, 13, ¶ 51-52, discloses the difference between the manual and automation costs. ¶ 9-11, 105, 109, 125-126, 154-155, 174-175).
Hirpara further teaches that the decision whether to automate should account for the business criticality of the affected hardware and software components as recorded in a configuration management database (¶ 54-55, 113).
Hirpara does not specifically teach the set of comparison metrics including a drift metric representing a likelihood of variation between separate executions of the manual software development task determined based on the set of manual metrics and a devices affected metric; determining a network risk profile, the network risk profile based on: determining a stability score of a network, the network coupled to the automation software and the manual software development task, based on the drift metric; generating a criticality score based on the set of manual metrics and a devices affected metric; and generating the network risk profile based on the stability score and the criticality score.
However, Vasseur teaches assessing the risk that changes applied to a network including automatically applied changes that disrupts the network (¶ 68-69, 136).
Vasseur teaches a variation metric determined based on a device affected metric (¶ 122, 138, disclose how a new configuration would be from a previous network configuration based on a recommendation. ¶ 139-145, disclose the result of the calculations of variation between executed changes across the various devices that had modifications done to them.);
Vasseur teaches determining a stability score of a network, the network couped to the automation software and the task, based on the variation metric (¶ 136-138, the configuration measure to determine the risk that applying a change will disrupt the network. ¶ 143-144. This limitation is analogous to the applicant limitation which discloses that the stability score is representing the likelihood of drift and whether drift exceeds a threshold indicative of intolerable drift impairing network stability.);
Vasseur teaches generating a criticality score based on the devices affected metric (¶ 143-146, a risk score estimator may take into account how much of the network traffic is dependent on the network devices that are impacted and the number of users/flows impacted by the change is a critical variable. ¶ 144-145, weighs the affected sessions based on criticality. ¶ 146, computes a centrality index. ¶ 147-150, 76);
Vasseur teaches generating a network risk profile based on a stability score and a criticality score (¶ 136-138, discloses a risk score reflecting the impact of change on the network, as a value or as low, medium, high. ¶ 138-139, discloses taking into account the device impact factors. ¶ 143-151, discloses a risk time profile based on various scenarios. ¶ 152-154, Fig. 9);
Vasseur teaches outputting the network risk profile (¶ 136-137, 155-156, discloses providing the risk score and risk profile to an interface.)
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Hirpara to include/perform the combination of configuration and risk factors, as taught/suggested by Vasseur. This known technique is applicable to the system of Hirpara as they both share characteristics and capabilities, namely, they are directed to performance in an IT system. One of ordinary skill in the art would have recognized that applying the known technique of Vasseur would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Vasseur to the teachings of Hirpara would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such network risk profile features into similar systems. Further, applying an email address as an alias would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for a result that is more complete for making risk based assessments.
Hirpara in combination with Vasseur does not specifically teach that the manual task is a software development task, that the request comprises an API call, or that the drift metric represents a likelihood of variation between separate executions of the manual task.
Kim teaches a manual software development task (¶ 59, discloses identifying manual and/or repetitive tasks (e.g., a set of one or more actions that a user repeatedly takes) which may be automated. ¶ 56, identifying tasks being performed by a user. ¶ 61, discloses identifying tasks that are frequently performed by employees and assess the economic viability of automating the task. ¶ 113, 37);
Kim teaches an application programming interface ("API") call to execute (¶ 90, 102, 114-115, discloses when Scout Service may proceed to automate the task if the automation score exceeds the threshold by performing act of generating software robot(s) to perform the task. ¶ 60, 83, 92, discloses APIs for system calls for execution.);
Kim teaches variation between separate executions of the manual task, representing a likelihood (¶ 107-108, discloses the same manually performed task and determines whether those instances repeat and performs an entropy calculation on various features. ¶ 112, 14, 37, Table 4).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Hirpara to include/perform the execution of a manual software development task, as taught/suggested by Kim. This known technique is applicable to the system of Hirpara as they both share characteristics and capabilities, namely, they are directed to comparing task based on work. One of ordinary skill in the art would have recognized that applying the known technique of Kim would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Kim to the teachings of Hirpara would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such manual software development task features into similar systems. Further, applying the using data related to manual software development tasks would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for organizations to reallocate staff to higher‑value activities, increasing strategic value by freeing human resources from repetitive actions.
Regarding claims 3, 12, Hirpara teaches the method of claim 1, wherein receiving the set of manual metrics comprises: receiving a candidate entry (¶ 89-98, 101, 105, disclose entering information related to a manual metrics including person hours);
validating one or more of a field value, task value, or hour value, associated with the candidate entry (¶ 9-11, discloses checking task values. ¶ 87-99, disclose and costs associated with manual operations. ¶ 101, 105);
and storing the candidate entry as the set of manual metrics (¶ 9-11, discloses checking task and storing task values. ¶ 101, 105).
Regarding claim 6, 15, Hirpara teaches the method of claim 1, wherein outputting the set of comparison metrics comprises: receiving a request to display the set of comparison metrics and a user configuration associated with the request (¶ 51, 85, 99, 105, discloses comparing manual operations vs automated operations, Fig. 4, 5, 13);
based on the request and the user configuration associated with the request: displaying, via a first display interface, a first subset of the set of comparison metrics including an hours saved metric included within the set of comparison metrics; or displaying, via a second display interface, a second subset of the set of comparison metrics including a stability score of a network (¶ 105, 107, 174-175, discloses comparing manual operations vs automated operations, Fig. 4, 5, 13, 18, 19).
Regarding claims 7, 16, the combination of Hirpara, Vasseur, and Kim teach the limitations of claim 1, and 10, the combination further teaches responsive to the network risk profile exceeding a threshold risk score representing network instability, automatically implementing the automation software to reduce the network instability.
Specifically Hirpara teaches that the risk an issue is a reason to automate resolution of that issue (¶ 55, 113, the business benefits of automating an issue. ¶ 43, 55).
Hirpara does not specifically teach a threshold risk.
Vasseur teaches a network risk profile, including a threshold risk level representing network instability, and using that risk profile to govern the automatic implementation of automated changes in the network (¶ 137, discloses a risk score in categories. ¶ 155, 69, 108, discloses the system could similarly use the risk score and risk time profile information to decide whether to implement a recommendation. ¶ 63, 74).
Kim teaches, responsive to a score exceeding a threshold, automatically implementing automation software. (¶ 114, 102, 115, Kim determines whether a tasks automation score exceeds a threshold and if so it automates the task by a software robot).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Hirpara to include/perform responsive to the network risk profile exceeding a threshold risk score representing network instability, the automation software is automatically implemented to reduce the network instability, as taught/suggested by Vasseur and Kim. This known technique is applicable to the system of Hirpara as they both share characteristics and capabilities, namely, they are directed to providing automation to a system. One of ordinary skill in the art would have recognized that applying the known technique of Vasseur and Kim would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Vasseur and Kim to the teachings of Hirpara would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such automation features into similar systems. Further, applying automation to a task would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for organizations to reallocate staff to higher‑value activities, increasing strategic value by freeing human resources from repetitive actions.
Regarding claim 10, Hirpara teaches one or more processors configured to: receive a set of manual metrics corresponding to execution of a manual task (¶ 87-93, 98, 105, discloses calculating the cost of manual operations. ¶ 39, 40, 42, 178-181, disclose the claimed technology. ¶ 9-11);
receive a request to execute an automation software (¶ 10-11, 51-52, discloses a request and executing on automation software. ¶ 58, 103);
generate a set of automation metrics corresponding to an execution of the automation software (¶ 48-49, discloses the cost of automated operations. ¶ 96-98, discloses the cost of automated solutions. ¶ 9-11, 103-105, 126);
generate a set of comparison metrics based on comparing the set of manual metrics with the set of automation metrics (¶ 51-52, discloses the difference between the manual and automation costs. ¶ 9-11, 85, 109, 125-126, 139);
and output the set of comparison metrics (Fig. 4, 5, 13, ¶ 51-52, discloses the difference between the manual and automation costs. ¶ 9-11, 105, 109, 125-126, 154-155).
Hirpara further teaches that the decision whether to automate should account for the business criticality of the affected hardware and software components as recorded in a configuration management database (¶ 54-55, 113).
Hirpara does not specifically teach the set of comparison metrics including a drift metric representing a likelihood of variation between separate executions of the manual software development task determined based on the set of manual metrics and a devices affected metric; determining a network risk profile, the network risk profile based on: determining a stability score of a network, the network coupled to the automation software and the manual software development task, based on the drift metric; generating a criticality score based on the set of manual metrics and a devices affected metric; and generating the network risk profile based on the stability score and the criticality score.
However, Vasseur teaches assessing the risk that changes applied to a network including automatically applied changes that disrupts the network (¶ 68-69, 136).
Vasseur teaches a variation metric determined based on a device affected metric (¶ 122, 138, disclose how a new configuration would be from a previous network configuration based on a recommendation. ¶ 139-145, disclose the result of the calculations of variation between executed changes across the various devices that had modifications done to them.);
Vasseur teaches determining a stability score of a network, the network couped to the automation software and the task, based on the variation metric (¶ 136-138, the configuration measure to determine the risk that applying a change will disrupt the network. ¶ 143-144. This limitation is analogous to the applicant limitation which discloses that the stability score is representing the likelihood of drift and whether drift exceeds a threshold indicative of intolerable drift impairing network stability.);
Vasseur teaches generating a criticality score based on the devices affected metric (¶ 143-146, a risk score estimator may take into account how much of the network traffic is dependent on the network devices that are impacted and the number of users/flows impacted by the change is a critical variable. ¶ 144-145, weighs the affected sessions based on criticality. ¶ 146, computes a centrality index. ¶ 147-150, 76);
Vasseur teaches generating a network risk profile based on a stability score and a criticality score (¶ 136-138, discloses a risk score reflecting the impact of change on the network, as a value or as low, medium, high. ¶ 138-139, discloses taking into account the device impact factors. ¶ 143-151, discloses a risk time profile based on various scenarios. ¶ 152-154, Fig. 9);
Vasseur teaches outputting the network risk profile (¶ 136-137, 155-156, discloses providing the risk score and risk profile to an interface.)
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Hirpara to include/perform the combination of configuration and risk factors, as taught/suggested by Vasseur. This known technique is applicable to the system of Hirpara as they both share characteristics and capabilities, namely, they are directed to performance in an IT system. One of ordinary skill in the art would have recognized that applying the known technique of Vasseur would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Vasseur to the teachings of Hirpara would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such network risk profile features into similar systems. Further, applying an email address as an alias would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for a result that is more complete for making risk based assessments.
Hirpara in combination with Vasseur does not specifically teach that the manual task is a software development task or that the drift metric represents a likelihood of variation between separate executions of the manual task.
Kim teaches a manual software development task (¶ 59, discloses identifying manual and/or repetitive tasks (e.g., a set of one or more actions that a user repeatedly takes) which may be automated. ¶ 56, identifying tasks being performed by a user. ¶ 61, discloses identifying tasks that are frequently performed by employees and assess the economic viability of automating the task. ¶ 113, 37);
Kim teaches variation between separate executions of the manual task, representing a likelihood (¶ 107-108, discloses the same manually performed task and determines whether those instances repeat and performs an entropy calculation on various features. ¶ 112, 14, 37, Table 4).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Hirpara to include/perform the execution of a manual software development task, as taught/suggested by Kim. This known technique is applicable to the system of Hirpara as they both share characteristics and capabilities, namely, they are directed to comparing task based on work. One of ordinary skill in the art would have recognized that applying the known technique of Kim would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Kim to the teachings of Hirpara would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such manual software development task features into similar systems. Further, applying the using data related to manual software development tasks would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for organizations to reallocate staff to higher‑value activities, increasing strategic value by freeing human resources from repetitive actions.
Regarding claim 19, Hirpara teaches non-transitory computer readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to: receive a set of manual metrics corresponding to execution of a manual task (¶ 87-93, 98, 105, discloses calculating the cost of manual operations. ¶ 39, 40, 42, 178-181, disclose the claimed technology. ¶ 9-11);
receive a request to execute an automation software (¶ 10-11, 51-52, discloses a request and executing on automation software. ¶ 58, 103);
generate a set of automation metrics corresponding to an execution of the automation software (¶ 48-49, discloses the cost of automated operations. ¶ 96-98, discloses the cost of automated solutions. ¶ 9-11, 103-105, 126);
generate a set of comparison metrics based on comparing the set of manual metrics with the set of automation metrics (¶ 51-52, discloses the difference between the manual and automation costs. ¶ 9-11, 85, 109, 125-126, 139);
and output the set of comparison metrics (Fig. 4, 5, 13, ¶ 51-52, discloses the difference between the manual and automation costs. ¶ 9-11, 105, 109, 125-126, 154-155).
Hirpara further teaches that the decision whether to automate should account for the business criticality of the affected hardware and software components as recorded in a configuration management database (¶ 54-55, 113).
Hirpara does not specifically teach the set of comparison metrics including a drift metric representing a likelihood of variation between separate executions of the manual software development task determined based on the set of manual metrics and a devices affected metric; determining a network risk profile, the network risk profile based on: determining a stability score of a network, the network coupled to the automation software and the manual software development task, based on the drift metric; generating a criticality score based on the set of manual metrics and a devices affected metric; and generating the network risk profile based on the stability score and the criticality score.
However, Vasseur teaches assessing the risk that changes applied to a network including automatically applied changes that disrupts the network (¶ 68-69, 136).
Vasseur teaches a variation metric determined based on a device affected metric (¶ 122, 138, disclose how a new configuration would be from a previous network configuration based on a recommendation. ¶ 139-145, disclose the result of the calculations of variation between executed changes across the various devices that had modifications done to them.);
Vasseur teaches determining a stability score of a network, the network couped to the automation software and the task, based on the variation metric (¶ 136-138, the configuration measure to determine the risk that applying a change will disrupt the network. ¶ 143-144. This limitation is analogous to the applicant limitation which discloses that the stability score is representing the likelihood of drift and whether drift exceeds a threshold indicative of intolerable drift impairing network stability.);
Vasseur teaches generating a criticality score based on the devices affected metric (¶ 143-146, a risk score estimator may take into account how much of the network traffic is dependent on the network devices that are impacted and the number of users/flows impacted by the change is a critical variable. ¶ 144-145, weighs the affected sessions based on criticality. ¶ 146, computes a centrality index. ¶ 147-150, 76);
Vasseur teaches generating a network risk profile based on a stability score and a criticality score (¶ 136-138, discloses a risk score reflecting the impact of change on the network, as a value or as low, medium, high. ¶ 138-139, discloses taking into account the device impact factors. ¶ 143-151, discloses a risk time profile based on various scenarios. ¶ 152-154, Fig. 9);
Vasseur teaches outputting the network risk profile (¶ 136-137, 155-156, discloses providing the risk score and risk profile to an interface.)
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Hirpara to include/perform the combination of configuration and risk factors, as taught/suggested by Vasseur. This known technique is applicable to the system of Hirpara as they both share characteristics and capabilities, namely, they are directed to performance in an IT system. One of ordinary skill in the art would have recognized that applying the known technique of Vasseur would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Vasseur to the teachings of Hirpara would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such network risk profile features into similar systems. Further, applying an email address as an alias would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for a result that is more complete for making risk based assessments.
Hirpara in combination with Vasseur does not specifically teach that the manual task is a software development task or that the drift metric represents a likelihood of variation between separate executions of the manual task.
Kim teaches a manual software development task (¶ 59, discloses identifying manual and/or repetitive tasks (e.g., a set of one or more actions that a user repeatedly takes) which may be automated. ¶ 56, identifying tasks being performed by a user. ¶ 61, discloses identifying tasks that are frequently performed by employees and assess the economic viability of automating the task. ¶ 113, 37);
Kim teaches variation between separate executions of the manual task, representing a likelihood (¶ 107-108, discloses the same manually performed task and determines whether those instances repeat and performs an entropy calculation on various features. ¶ 112, 14, 37, Table 4).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Hirpara to include/perform the execution of a manual software development task, as taught/suggested by Kim. This known technique is applicable to the system of Hirpara as they both share characteristics and capabilities, namely, they are directed to comparing task based on work. One of ordinary skill in the art would have recognized that applying the known technique of Kim would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Kim to the teachings of Hirpara would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such manual software development task features into similar systems. Further, applying the using data related to manual software development tasks would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for organizations to reallocate staff to higher‑value activities, increasing strategic value by freeing human resources from repetitive actions.
Claim(s) 2, 4, 5, 11, 13, 14, 20, is/are rejected under 35 U.S.C. 103 as being unpatentable over Hirpara et al. (US 20180046966 A1) in view of Vasseur et al. (US 20240323096 A1) in view of Kim (US 20180181377 A1) in further view of Madhavji (US 20250299146 A1).
Regarding claims 2, 11, 20, Hirpara teaches the method of claim 1, further comprising: in response to receiving the request to execute the automation software, identifying a set of solution cost metrics associated with the automation software and including a development cost, an ongoing maintenance cost (¶ 38, 51, 90-105, 109 discloses the cost of automation including implementation and use. ¶ 126, 152, 155, 173-175);
and wherein generating the set of comparison metrics is based on the set of solution cost metrics (¶ 38, 51, 90-105, 109 discloses the cost of automation including implementation and use. ¶ 126, 152, 155, 173-175).
Hirpara does not specifically teach a licensing cost.
However, Madhavji teaches the method of claim 1, further comprising: in response to receiving the request to execute the automation software, identifying a set of solution cost metrics associated with the automation software and including a development cost, an ongoing maintenance cost, and a licensing cost (¶ 29, 51, 75).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Hirpara to include/perform a licensing cost, as taught/suggested by Madhavji. This known technique is applicable to the system of Hirpara as they both share characteristics and capabilities, namely, they are directed to comparing task based on work (automated and or manual). One of ordinary skill in the art would have recognized that applying the known technique of Madhavji would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Madhavji to the teachings of Hirpara would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such cost features into similar systems. Further, applying a licensing cost would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow a more adequate picture of the overall cost of the automation.
Regarding claims 4, 13, Hirpara teaches the method of claim 3, further comprising: in response to determining an opportunity cost metric exceeds a cost threshold value, generating a flag for output (¶ 51-52, discloses calculating an opportunity cost. ¶ 47-50, discloses the cost comparison between manual and automated operations. ¶ 98-105, discloses when the equilibrium cost requesting a resolution. ¶ 86-93, 108-109);
wherein the opportunity cost metric is determined by steps comprising: determining a costs saved metric based on an hours saved metric included within the set of comparison metrics (abstract, ¶ 38, 47-50, discloses cost savings, ¶ 51-52, discloses calculating an opportunity cost. ¶ 98-105, discloses when the equilibrium cost requesting a resolution. ¶ 86-93, 108-109).
Hirpara does not specifically teach a field occupancy metric.
However, Madhavji teaches determining a field occupancy metric based on the field value (¶ 51, discloses costs associated with the teams and employees involved. ¶ 93-98, Fig. 4-6);
and determining the opportunity cost metric based on the cost saved metric and the field occupancy metric. (¶ 51, discloses costs associated with the teams and employees involved. ¶ 98, discloses a cost efficiency and saved value for the various worker types. ¶ 93-97, Fig. 4-6).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Hirpara to include/perform a field occupancy metric, as taught/suggested by Madhavji. This known technique is applicable to the system of Hirpara as they both share characteristics and capabilities, namely, they are directed to comparing task based on work (automated and or manual). One of ordinary skill in the art would have recognized that applying the known technique of Madhavji would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Madhavji to the teachings of Hirpara would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such metric features into similar systems. Further, applying a field occupancy metric would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for improved space planning and resource allocation.
Regarding claims 5, 14, Hirpara teaches both a manual and automated configuration but does not specifically teach wherein the set of automation metrics includes a success rate score, an automation length metric and an automation configuration.
However, Madhavji teaches wherein the set of automation metrics includes a success rate score, an automation length metric and an automation configuration (¶ 33, 36, 56, 85, discloses a success rate. ¶ 30, 33, 40, 52, 60, 68, 70, discloses an automation length metric. ¶ 90, discloses an automation configuration, Fig. 4-6).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Hirpara to include/perform the automation metrics as claimed, as taught/suggested by Madhavji. This known technique is applicable to the system of Hirpara as they both share characteristics and capabilities, namely, they are directed to comparing task based on work (automated and or manual). One of ordinary skill in the art would have recognized that applying the known technique of Madhavji would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Madhavji to the teachings of Hirpara would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such metric features into similar systems. Further, applying the automation metrics as claimed would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for improved space planning and resource allocation.
Claim(s) 8, 17, is/are rejected under 35 U.S.C. 103 as being unpatentable over Hirpara et al. (US 20180046966 A1) in view of Vasseur et al. (US 20240323096 A1) in view of Kim (US 20180181377 A1) in further view of Stergioudis et al. (US 20210400075 A1).
Regarding claims 8, 17, Hirpara, Vasseur, and Kim teach the limitations of claims 1, 10, including outputting the set of comparison metrics and the network risk profile. The combination does not specifically teach identifying, based on user credentials, a first set of users and a second set of users separately requesting access to the comparison metrics: outputting, to the first set of users, the comparison metrics and the network risk profile; and outputting, to the second set of users, the comparison metrics and restricting access to the network risk profile.
However, Stergioudis teaches identifying, based on user credentials, a first set of users and a second set of users separately requesting access to the comparison metrics: outputting, to the first set of users, the comparison metrics and the network risk profile; and outputting, to the second set of users, the comparison metrics and restricting access to the network risk profile (¶ 3, discloses prompting the user for credentials. ¶ 60, 65, discloses authenticating user and identifying one or more resources the user can access. ¶ 5, 8, disclose granting users to specified services. ¶ 4, 128-129, discloses submitting an access request. ¶ 5, 125-129, disclose requests not satisfying the policy therefore restricting access.).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Hirpara to include/perform the restricting access to the network risk profile, as taught/suggested by Stergioudis. This known technique is applicable to the system of Hirpara as they both share characteristics and capabilities, namely, they are directed to accessing resources in a network. One of ordinary skill in the art would have recognized that applying the known technique of Stergioudis would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Stergioudis to the teachings of Hirpara would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such resource features into similar systems. Further, applying restricting access to the network risk profile would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for credential based access control to restrict the users that should not have access and to protect the system.
Claim(s) 9, 18, is/are rejected under 35 U.S.C. 103 as being unpatentable over Hirpara et al. (US 20180046966 A1) in view of Vasseur et al. (US 20240323096 A1) in view of Kim (US 20180181377 A1) in further view of Stergioudis et al. (US 20210400075 A1) in further view of Cella et al. (US 20240144181 A1).
Regarding claims 9, 18, the combination of Hirpara, Vasseur, Kim, and Stergioudis teaches the limitations of claims 8, 17, but does not specifically teach a network risk profile exceeding a threshold, generating an alert.
However, Cella teaches the method further comprises, in response to determining the network risk profile exceeds a threshold risk value, generating an alert (¶ 16, 18, 27-32, discloses the network risk threshold. And also discloses an alert an alert for mitigating risk. ¶ 245 discloses associated risks. ¶ 1069-1071, 3247-3249, 3116, 3168).
It would have been obvious to one of ordinary skill in the art at the time of filing to modify Hirpara to include/perform the features of the risk profile as claimed, as taught/suggested by Cella. This known technique is applicable to the system of Hirpara as they both share characteristics and capabilities, namely, they are directed to comparing tasks based on work. One of ordinary skill in the art would have recognized that applying the known technique of Cella would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of Cella to the teachings of Hirpara would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such risk profile features into similar systems. Further, applying the risk profile features would have been recognized by those of ordinary skill in the art as resulting in an improved system that would allow for the user the ability to take notice when there is a possible issue.
Other pertinent prior art includes Bassin et al. (US 20110066490 A1) which discloses generating a cost model and generating a resource allocation plan based on the test model, the resource base, and the cost model. Habaux (US 20230124106 A1) which discloses predicting a process metric associated with a process. Shikano (US 20160092804 A1) discloses an operations improvement apparatus for improving the operation of an information processing system.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 JAMIE H AUSTIN whose telephone number is (571)272-7363. The examiner can normally be reached Monday, Tuesday, Thursday, Friday 7am-2pm.
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, Brian Epstein can be reached at (571) 270 5389. 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.
JAMIE H. AUSTIN
Examiner
Art Unit 3625
/JAMIE H AUSTIN/Primary Examiner, Art Unit 3625
Prosecution Insights