Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Application
The following is a Final Office Action. In response to Examiner's communication on 07/15/2025, Applicant on 10/15/2025, amended Claims 1, 5, 8, 9, 11, 17, 18, 20. Claims 1-20 are now pending in this application and have been rejected below.
Response to Amendment
Applicants’ amendments are insufficient to overcome the 35 USC 101 rejections set forth in the previous action. The rejections have been updated to address the amendments and maintained below.
Applicants’ amendments render moot the 35 USC 103 rejections set forth in the previous action in view of new and updated grounds for rejection necessitated by Applicants’ amendments. Therefore, these rejections are withdrawn in view of the new grounds for rejection necessitated by Applicants’ amendments, as set forth below.
Response to Arguments – 35 USC § 101
Applicant's arguments with respect to the 35 USC 101 rejections have been fully considered but they are not persuasive. Applicant asserts that submitted amendments render the 35 USC § 101 rejection moot. Without further clarification as to the grounds for said assertion, Examiner respectfully notes that the rejection has been updated to address the amendments and maintained below.
Response to Arguments – 35 USC § 102 and 35 USC § 103
Applicant' s arguments with respect to the rejection of Claims 1-20 under 35 USC 103 have been considered but are moot in light of new grounds of rejections necessitated by applicant’s amendments.
Applicant asserts that there is a lack of a “key” functionality in the Saraf and Esman references. However, Examiner respectfully disagrees.
In light of Lines 14-28 on Page 17 of Applicant’s specification, we understand a key to be an identifier that corresponds to a process and that can be used to label individual transactional milestones. In the Saraf reference, this is understood to be the identifier of a particular business group that a process can correspond to.
In [0113] of Saraf, “An information section 1740 may list information about the process (e.g., a function, one or more business groups, a process, and the like), and/or operational data (e.g., a start date, a creation date, a roll out date, a rating, and/or an indication of publication). In the questionnaire section, one or more tabs (e.g., process, people, system, compliance, external events, and risk and control indicators) may be used to display questions used to gather information about the process and/or the controls being used to mitigate the process”.
Applicant further asserts Saraf combined with Esman fail to teach “providing, by the device, a representation of the sequence of transactional milestones with indications of the individual risk assessments and the overall risk assessment for the sequence of transactional milestones for display by a user interface”. Examiner respectfully disagrees.
In [0115], "FIG. 19 shows an illustrative heat map 1900. The heat map may include a risk score associated with the risk management project". We understand this graphical rendering of the overall process and risk score to correspond to the display as claimed.
As the remainder of Applicant’s arguments pertain to either substantially similar or newly introduced limitations in independent Claims 1, 11 and 20, Examiner respectfully notes that these arguments are moot in light of updated grounds of rejection necessary to address amendments. Dependent Claims 2-10, 12-19 have also been updated to address the amendments and maintained 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 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
101 Analysis – Step 1
The claims are directed to a method and apparatus. Therefore, the claim is directed to at least one of the four statutory categories.
101 Analysis – Step 2A
Regarding Prong 1 of the Step 2A analysis in the MPEP, the claims are to be analyzed to determine whether they recite subject matter that is directed to a judicial expectation, namely a law of nature, a natural phenomenon, or one of the follow groups of abstract ideas: a) mathematical concepts, b) certain methods of organizing human activity, and/or c) mental processes.
Independent Claim 1 includes limitations that recite an abstract idea and will henceforth be used as a representative claim for the 101 rejection until otherwise noted. Claim 1 recites:
A method, comprising: identifying, by a device, a sequence of transactional milestones of a service associated with an online application and based at least in part on configuration data, the configuration data including keys associated with individual transactional milestones of the sequence of transactional milestones; determining, by the device, individual risk assessments for the individual transactional milestones, based in part on the associated keys and any vulnerabilities associated with code used to perform the individual transactional milestones, the individual risk assessments being determined such that the device processes a limited number of keys in a manner that saves processing power of the device; determining, by the device and based on the individual risk assessments, an overall risk assessment for the sequence of transactional milestones, the overall risk assessment being determined such that the device allocates computing resources in a manner that enhances security of the online application; and providing, by the device, a representation of the sequence of transactional milestones with indications of the individual risk assessments and the overall risk assessment for the sequence of transactional milestones for display by a user interface.
The examiner submits that the foregoing bolded limitation(s) constitute an abstract idea because under its broadest reasonable interpretation, the claim covers a mental process.
“A method, comprising: identifying…”, “determining, by the device, individual risk assessment”, “determining…an overall risk assessment for the sequence of transactional milestones”, “and providing…a representation of the sequence” all recite abstract ideas - namely, mental processes that could be performed by a human with a pen and paper, per the MPEP, merely adapting them into the context of a technological environment with computing parts does not preclude them from being abstract.
Accordingly, the claim recites at least one abstract idea.
Independent Claims 11 and 20 recite abstract ideas for analogous reasons.
101 Analysis – Step 2A, Prong II
Regarding Prong II of the Step 2A analysis in the MPEP, the claims are to be analyzed to determine whether the claim, as a whole, integrates the abstract into practical application. As noted in the MPEP, it must be determined whether any additional elements in the claim beyond the judicial exception integrate the exception into a practical application in a manner that imposes a meaningful limit on the judicial exception. The courts have indicated that additional elements, such as merely using a computer to implement an abstract idea, adding insignificant extra solution activity, or generally linking use of a judicial exception to a particular technological environment or field of use do not integrate a judicial exception into a “practical application.
In the present case, the additional limitations beyond the above-noted abstract idea are as follows (where the underlined portions are the “additional limitations” while the bolded portions continue to represent the “abstract idea”):
A method, comprising: identifying, by a device, a sequence of transactional milestones of a service associated with an online application and based at least in part on configuration data, the configuration data including keys associated with individual transactional milestones of the sequence of transactional milestones; determining, by the device, individual risk assessments for the individual transactional milestones, based in part on the associated keys and any vulnerabilities associated with code used to perform the individual transactional milestones, the individual risk assessments being determined such that the device processes a limited number of keys in a manner that saves processing power of the device; determining, by the device and based on the individual risk assessments, an overall risk assessment for the sequence of transactional milestones, the overall risk assessment being determined such that the device allocates computing resources in a manner that enhances security of the online application; and providing, by the device, a representation of the sequence of transactional milestones with indications of the individual risk assessments and the overall risk assessment for the sequence of transactional milestones for display by a user interface.
For the following reason(s), the examiner submits that the above identified additional limitations do not integrate the above-noted abstract idea into a practical application. As it pertains to Claim 1, the additional elements in the claims include the “device”, as well as the rendering of a visual “for display by a user interface”. When considered in view of the claim as a whole, the additional elements do not integrate the abstract idea into a practical application because the additional elements are generic computing components that are merely used as a tool to perform the recited abstract idea and/or do no more than generally link the use of the recited abstract idea to a particular technological environment or field of use under Step 2A Prong Two. Independent Claims 11 and 20 recite limitations such as “an apparatus”, “one or more network interfaces”, “a processor”, “a memory”, and “a tangible, non-transitory computer-readable medium, but these do not integrate the abstract idea into a practical application by analogous reasoning.
Thus, taken alone, the additional elements do not integrate the abstract idea into a practical application. Further, looking at the additional limitation(s) as an ordered combination or as a whole, the limitation(s) add nothing that is not already present when looking at the elements taken individually. For instance, there is no indication that the additional elements, when considered as a whole, reflect an improvement in the functioning of a computer or an improvement to another technology or technical field, apply or use the above-noted judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, implement/use the above-noted judicial exception with a particular machine or manufacture that is integral to the claim, effect a transformation or reduction of a particular article to a different state or thing, or apply or use the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is not more than a drafting effort designed to monopolize the exception (MPEP § 2106.05). Accordingly, the additional limitation(s) does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing an abstract idea.
Claims 11 and 20 recite substantially similar limitations and therefore do not integrate the recited abstract ideas into a practical application by analogous reasoning.
Claims 3-10, 13-19 do not recite additional elements beyond those found in Claims from which they are dependent and therefore do not integrate the abstract ideas into a practical application.
Claims 2, 12 additionally recite “receive, via the user interface, a selection…” and “provide, in response to receiving the selection…a listing…for display by the user interface”. These limitations do not integrate the recited abstract ideas into a practical application by analogous reasoning as above.
101 Analysis – Step 2B
Regarding Step 2B of the MPEP, representative independent claim 1 does not include additional elements (considered both individually and as an ordered combination) that are sufficient to amount to significantly more than the judicial exception for the same reasons to those discussed above with respect to determining that the claim does not integrate the abstract idea into a practical application. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to generic computing components that do not serve to integrate the recited abstract ideas into a practical application or amount to significantly more.
Claims 11 and 20 recite substantially similar limitations and therefore do not integrate the recited abstract ideas into a practical application or amount to significantly more by analogous reasoning.
Claims 3-10, 13-19 do not recite additional elements beyond those found in Claims from which they are dependent and therefore do not integrate the abstract ideas into a practical application or amount to significantly more.
Claims 2, 12 additionally recite “receive, via the user interface, a selection…” and “provide, in response to receiving the selection…a listing…for display by the user interface”. These limitations do not integrate the recited abstract ideas into a practical application or amount to significantly more by analogous reasoning as above.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Saraf(US 20150227869 A1) in view of Esman(US 20200226607 A1).
Claim 1
As to Claim 1,
Saraf teaches:
A method, comprising: identifying, by a device, a sequence of transactional milestones
We understand the processes performed to be transactional milestones in [0062], "For example, the fields may include an indicator mapping level (e.g., process, control, risk, and the like), a function (e.g., operations, enterprise functions, and the like), business information (e.g., a line of business, a business segment, a business unit, and the like), and/or a process, where the user may select a process from a list of entered processes". Support for sequential, transactional data can be found in [0106], "For example, the screen 900 may be displayed when a user selects a "generate data template" from a menu. The user may then specify a template name and be able to add elements to the template using an "add new element" selection, which may be accessed via a menu option…Each element may be associated with one or more attributes. For example, a source attribute may correspond to a data elements associated with transactional data received from business sources (e.g., a loan number, a mortgage amount, and the like)....A sequence element, defines an arrangement order for the data elements as they would appear on the final user interface screen 318. The order may be selected to provide easy navigation”.
of a service associated with an online application;
In [0052], "The risk self-assessment tool 310 may also be a web-based tool that may allow for different business units, at different geographical locations, to access a centralized system for managing different risk mitigation projects. An example of different user interface screens provided by the risk self-assessment tool 310 during this process are discussed below in reference to FIGS. 15-19".
and based at least in part on configuration data, the configuration data including keys associated with individual transactional milestones of the sequence of transactional milestones
In [0113], “An information section 1740 may list information about the process (e.g., a function, one or more business groups, a process, and the like), and/or operational data (e.g., a start date, a creation date, a roll out date, a rating, and/or an indication of publication). In the questionnaire section, one or more tabs (e.g., process, people, system, compliance, external events, and risk and control indicators) may be used to display questions used to gather information about the process and/or the controls being used to mitigate the process”. In light of Lines 14-28 of Page 17 of Applicant’s specification, we understand the identifier of a business group to be the key that maps to individual transactional milestones(as outlined above, in Saraf, given processes).
determining, by the device, individual risk assessments for the individual transactional milestones
We have that each process can be analyzed for risk - in [0043], "The data repository 320 may be configured to store information about one or more business processes…previously measured and/or analyzed historical process data, risk management information, one or more risk scores, one or more compliance reports…For example, the data repository may store historical process data that may be used perform one or more calculations. For example, the historical information and/or current data may be analyzed to calculate a regression, a trend analysis, a risk score, a compliance score, a key control indicator metric, a key risk indicator metric, and/or the like." These risk assessments being individualized is supported in [0115], "In some cases, the heat map section 1930 may include an overall risk score associated with the individual processes".
based in part on the associated keys,
[0051] describes the intake of information from users affiliated with a given business unit, which we previously understood to be our keys, “At the beginning of the month, a questionnaire associated with different elements of an operational risk and/or compliance issues associated with the identified risk may be provided to the responsible business unit teams. The team members may access the questionnaire via a user interface screen 318 of the risk self-assessment tool 310 to provide their input. The responses received may be communicated by the risk self-assessment tool 310 to the risk analysis system 340 for analysis based on different likelihood metrics…”
the individual risk assessments being determined such that the device processes a limited number of keys in a manner that saves processing power of the device
In [0051], “The risk self-assessment tool 310 may be configured to examine the risk exposure of multiple business units at over a regular time period. For example, the risk self-assessment tool 310 may trigger a monthly review of each identified risk for the different business units of an organization. At the beginning of the month, a questionnaire associated with different elements of an operational risk and/or compliance issues associated with the identified risk may be provided to the responsible business unit teams. The team members may access the questionnaire via a user interface screen 318 of the risk self-assessment tool 310 to provide their input. The responses received may be communicated by the risk self-assessment tool 310 to the risk analysis system 340 for analysis based on different likelihood metrics”. Namely, while we can operate in batches, that batch size can be confined to the scope of currently relevant business units; it is implicit that limiting the batch size of how many business units we analyze from would thus require less analysis by the central risk analysis system, and therefore save processing power.
determining, by the device and based on the individual risk assessments, an overall risk assessment for the sequence of transactional milestones,
Again analogizing [0041], "The compliance system 350 may be capable of determining a composite compliance risk score at a project level. In some cases, the compliance system 350 may have the ability to determine the metric performance at the project level and, in some cases, at a higher level within the organization (e.g., a business group, a business segment, a line of business, and the like)".
and providing, by the device, a representation of the sequence of transactional milestones with indications of the individual risk assessments and the overall risk assessment for the sequence of transactional milestones for display by a user interface.
In [0115], "FIG. 19 shows an illustrative heat map 1900. The heat map may include a risk score associated with the risk management project". We have an indication of the overall risk score of the grouping of processes, as well as individual risk scores of each process.
Saraf does not disclose the remaining limitations.
However, Esman teaches:
… and any vulnerabilities associated with code used to perform the individual transactional milestones;
In [0129], "For example, a first data model object may define a broad set of data pertaining to e-mail activity generally, and another data model object may define specific datasets within the broad dataset, such as a subset of the e-mail data pertaining specifically to e-mails sent. Examples of data models can include electronic mail, authentication, databases, intrusion detection, malware, application state, alerts, compute inventory, network sessions, network traffic, performance, audits, updates, vulnerabilities, etc.". In [0134], "Data visualizations also can be generated in a variety of formats, by reference to the data model. Reports, data visualizations, and data model objects can be saved and associated with the data model for future use. The data model object may be used to perform searches of other data". In [0008], “The method further includes performing a search of the raw machine data according to the first risk definition, wherein a risk is identified based on the search of the raw machine data and performing an action based on identifying the risk”.
the overall risk assessment being determined such that the device allocates computing resources in a manner that enhances security of the online application;
In [0183], “Aggregate KPIs may be defined to provide a measure of service performance calculated from a set of service aspect KPI values; this aggregate may even be taken across defined timeframes and/or across multiple services. A particular service may have an aggregate KPI derived from substantially all of the aspect KPI's of the service to indicate an overall health score for the service”. In [0152], “The SPLUNK® APP FOR ENTERPRISE SECURITY provides various visualizations to aid in discovering security threats, such as a “key indicators view” that enables a user to view security metrics, such as counts of different types of notable events. For example, FIG. 8A illustrates an example key indicators view 800 that comprises a dashboard, which can display a value 801, for various security-related metrics, such as malware infections 802. It can also display a change in a metric value 803, which indicates that the number of malware infections increased by 63 during the preceding interval”. The idea of “allocates computing resources” is understood here to simply mean that component devices and sources being managed by the security system are managed for security.
Esman discloses a system for monitoring risk in the context of information technology(IT) management. Saraf discloses a system meant to monitor and assess risk at an organizational level. Each reference discloses means for facilitating risk management analysis. Extending the means for conducting and displaying analysis as recorded in Esman to the system of Saraf is applicable as they both pertain to the task of risk management.
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to apply the means for conducting and displaying analysis as taught in Esman to the system for monitoring risk as taught in Saraf. Motivation to do so comes from the fact that the claim is plainly directed to the predictable result of combining known items in the prior art, with the expected benefit that adopting the analytical methodology and display features of Esman would enable users to enrich their analysis and inform key stakeholders of relevant information.
Claim 11 and 20 are rejected as presenting substantially similar limitations as Claim 1.
Claim 2
As to Claim 2, Esman combined with Saraf teaches all the limitations of Claim 1 as discussed above.
Esman teaches:
The method as in claim 1, further comprising: receiving, at the device and via the user interface, a selection of a particular transactional milestone depicted in the representation; and providing, by the device and in response to receiving the selection, a listing of one or more vulnerabilities associated with the particular transactional milestone for display by the user interface.
Figure 15C shows a user interface offering the more granular view claimed here. In [0252], " As shown in FIG. 15C through 15E, additional groups of risk objects may be selected and grouped together for further processing. As described herein, a first group of selected risk objects 1561 is displayed, as described herein, within the user selection box 1560. Also as shown, a second group of selected risk objects 1581 is displayed within a user selection box 1580. Within this second group of selected risk objects 1581 shown in user selection box 1580, a first sub-group of selected risk objects 1590 is displayed within a user selection box 1591, and a second sub-group of selected risk objects 1595 are displayed within a user selection box 1596".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to apply the means for conducting and displaying analysis as taught in Esman to the system for monitoring risk as taught in Saraf. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 12 is rejected as presenting substantially similar limitations as Claim 2.
Claim 3
As to Claim 3, Saraf combined with Esman teaches all the limitations of Claim 1 as discussed above.
Saraf teaches:
The method as in claim 1, wherein the indications of the individual risk assessments in the representation correspond to different levels of application-based impact associated with execution of a corresponding transactional milestone.
In [0032], "In at least one arrangement, application server 210 may receive and/or store information about one or more risk elements, risk categories, and/or risk parameters; determine one or more exposure scores, impact scores, and/or likelihood scores; determine one or more risk element scores, risk category scores, and/or risk parameter scores; and/or otherwise process data related to risk evaluation. For example, application server 210 may receive and/or store information that may be used in determining an exposure score, an impact score, and/or a likelihood score for a risk element, and application server 210 subsequently may determine such scores, as well as an overall element score, for the risk element".
Claim 13 is rejected as presenting substantially similar limitations as Claim 3.
Claim 4
As to Claim 4, Saraf combined with Esman teaches all the limitations of Claim 3 as discussed above.
The method as in claim 3, wherein the application-based impact is calculated based on one or more of: a weighted parameter indicative of a priority of the corresponding transactional milestone to a user;
a configuration of the corresponding transactional milestone; or a level of interaction with a database associated with the corresponding transactional milestone.In [0287], "At optional step 2030, the risk monitoring system 1116 applies the one more selected logical operators to operate on or combine the risk objects based on the risk severity levels associated with the selected risk objects and/or groups of risk objects. For instance, the risk monitoring system 1116 may determine a combined or threshold risk severity level associated with the risk objects and/or groups of risk objects. Further, the risk monitoring system 1116 may determine whether a “threat” is detected based on the generated results, such as that a threat is detected when a combined risk severity level meets a particular threshold value".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to apply the means for conducting and displaying analysis as taught in Esman to the system for monitoring risk as taught in Saraf. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 14 is rejected as presenting substantially similar limitations as Claim 4.
Claim 5
As to Claim 5, Saraf combined with Esman teaches all the limitations of Claim 1 as discussed above.
Esman teaches:
The method as in claim 1, wherein an individual risk assessment for an individual transactional milestone is modified to prioritize the individual transactional milestone based on the overall risk assessment for the sequence of transactional milestones.
In [0153], "To facilitate identifying patterns among the notable events, each notable event can be associated with an urgency value (e.g., low, medium, high, critical), which is indicated in the incident review dashboard. The urgency value for a detected event can be determined based on the severity of the event and the priority of the system component associated with the event." Taking the overall risk assessment to incorporate factors such as system priority, we understand the adjustment of urgency values to reflect particularly important systems involved to encompass this limitation.
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to apply the means for conducting and displaying analysis as taught in Esman to the system for monitoring risk as taught in Saraf. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 6
As to Claim 6, Saraf combined with Esman teaches all the limitations of Claim 1 as discussed above.
Esman teaches:
The method as in claim 1, further comprising: providing a list of transactional milestones that prioritizes transactional milestones in the sequence of transactional milestones over transactional milestones in other sequences of transactional milestones.
In [0252], "As shown in FIG. 15C through 15E, additional groups of risk objects may be selected and grouped together for further processing. As described herein, a first group of selected risk objects 1561 is displayed, as described herein, within the user selection box 1560. Also as shown, a second group of selected risk objects 1581 is displayed within a user selection box 1580. Within this second group of selected risk objects 1581 shown in user selection box 1580, a first sub-group of selected risk objects 1590 is displayed within a user selection box 1591, and a second sub-group of selected risk objects 1595 are displayed within a user selection box 1596". On pages 30-31 of the specification, "Responsive to receiving such a selection, the device may provide a listing of one or more vulnerabilities associated with the particular transactional milestone for display by the user interface. Providing the listing may include providing a prioritized list of transactional milestones. For instance, a listing may be provided that prioritizes vulnerabilities associated with transactional milestones in the sequence of transactional milestones over vulnerabilities associated with transactional milestones in other sequences of transactional milestones. That is, the prioritization of the risk mitigation candidate transactions may include filtering a list of risk mitigation candidate transactions (and/or their associated vulnerabilities) to prioritize transactions (and/or their associated vulnerabilities) in the sequence of transactions over transactions (and/or their associated vulnerabilities) in the list that are not in the sequence of transactions". Thus, we take the focused view of selected risk objects, pertaining to a selected grouping of risk objects, to disclose this claim.
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to apply the means for conducting and displaying analysis as taught in Esman to the system for monitoring risk as taught in Saraf. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 15 is rejected as presenting substantially similar limitations as Claim 6.
Claim 7
As to Claim 7, Saraf combined with Esman teaches all the limitations of Claim 1 as discussed above.
Esman teaches:
The method as in claim 1, further comprising: annotating transactional milestones in the sequence of transactional milestones within a listing including transactional milestones in other sequences of transactional milestones.
In [0090], "In an embodiment, the monitoring component 112 may also monitor and collect performance data related to one or more aspects of the operational state of a client application 110 and/or client device 102. For example, a monitoring component 112 may be configured to collect device performance information by monitoring one or more client device operations, or by making calls to an operating system and/or one or more other applications executing on a client device 102 for performance information. Device performance information may include, for instance, a current wireless signal strength of the device, a current connection type and network carrier, current memory performance information, a geographic location of the device, a device orientation, and any other information related to the operational state of the client device." In [0214], "For example, as shown in FIG. 11, a monitoring component 112 could be included as a client application 110 within one of client devices 102, and this monitoring component 112 could be executed in conjunction with the risk monitoring system 1116, such that the client devices 102 could be implemented as part of the risk monitoring system 1116".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to apply the means for conducting and displaying analysis as taught in Esman to the system for monitoring risk as taught in Saraf. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 16 is rejected as presenting substantially similar limitations as Claim 7.
Claim 8
As to Claim 8, Saraf combined with Esman teaches all the limitations of Claim 1 as discussed above.
Saraf teaches:
The method as in claim 1, wherein the individual risk assessments for the individual transactional milestone are color-coded to a corresponding threat level.
In [0115], "A risk score may be calculated from the answers to the questions listed under each parameter section on the questionnaire. In some cases, the heat map section 1930 may include an overall risk score associated with the individual processes. The heat map may include a visual representation of a "heat" associated with the scores. For example, scores under a first threshold (e.g., low scores) may be colored with a first color (e.g., green) illustrating a low heat level, a score within a second range may indicate a medium heat level and may be colored with a different color (e.g., yellow) and higher scores, above a specified threshold may indicate a high risk associated with the process and may be colored with a third color (e.g., red)".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to apply the means for conducting and displaying analysis as taught in Esman to the system for monitoring risk as taught in Saraf. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 17 is rejected as presenting substantially similar limitations as Claim 8.
Claim 9
As to Claim 9, Saraf combined with Esman teaches all the limitations of Claim 1 as discussed above.
Saraf teaches:
The method as in claim 1, wherein the individual risk assessments for the individual transactional milestone are based on a threat likelihood associated with a corresponding transactional milestone.
In [0050], "As discussed above, the risk self-assessment tool 310 was designed to allow a user to track the operational risk at a process level and/or to facilitate self-assessment by the business unit personnel on operational risk parameters, compliance metrics, key control indicators, and/or key risk indicators. For each operational risk parameter, an objective and/or quantitative measure may be used to determine a risk score by the risk analysis system 340 by determining a rating based on a likelihood of the risk occurring, an impact on the process and/or line of business resulting from the risk, and an exposure to the risk. For example, the likelihood corresponds to the possibility of the risk event occurring based, at least in part, on historical data that may be stored in the data repository 320".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to apply the means for conducting and displaying analysis as taught in Esman to the system for monitoring risk as taught in Saraf. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 18 is rejected as presenting substantially similar limitations as Claim 9.
Claim 10
As to Claim 10, Saraf combined with Esman teaches all the limitations of Claim 1 as discussed above.
Esman teaches:
The method as in claim 9, wherein the threat likelihood is calculated based on one or more of: a vulnerable library presence; a threat event;
In [0152], "The SPLUNK® APP FOR ENTERPRISE SECURITY provides various visualizations to aid in discovering security threats, such as a “key indicators view” that enables a user to view security metrics, such as counts of different types of notable events. For example, FIG. 8A illustrates an example key indicators view 800 that comprises a dashboard, which can display a value 801, for various security-related metrics, such as malware infections 802. It can also display a change in a metric value 803, which indicates that the number of malware infections increased by 63 during the preceding interval. Key indicators view 800 additionally displays a histogram panel 804 that displays a histogram of notable events".
or an application environment associated with the corresponding transactional milestone.
In [0091], "In an embodiment, the monitoring component 112 may also monitor and collect other device profile information including, for example, a type of client device, a manufacturer and model of the device, versions of various software applications installed on the device, and so forth". In [0214], "Those skilled in the art will understand that FIG. 11 represents one example of a networked computer system, and other embodiments may use different arrangements, including arrangements in which the risk monitoring system 1116 is implemented, completely or in part, within any one of or any combination of client devices 102, host devices 106, and the data intake and query system 108. For example, as shown in FIG. 11, a monitoring component 112 could be included as a client application 110 within one of client devices 102, and this monitoring component 112 could be executed in conjunction with the risk monitoring system 1116, such that the client devices 102 could be implemented as part of the risk monitoring system 1116".
It would have been obvious to one having ordinary skill in the art at the effective filling date of the invention to apply the means for conducting and displaying analysis as taught in Esman to the system for monitoring risk as taught in Saraf. Motivation to do so comes from the same rationale as outlined above with respect to Claim 1.
Claim 19 is rejected as presenting substantially similar limitations as Claim 10.
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 THEODORE L XIE whose telephone number is (571)272-7102. The examiner can normally be reached M-F 9-5.
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, Rutao Wu can be reached at 571-272-6045. 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.
/THEODORE XIE/Examiner, Art Unit 3623 /RUTAO WU/Supervisory Patent Examiner, Art Unit 3623