DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendments
The action is responsive to the Applicant’s Amendment filed on 2/05/2026. Claims 1, 3-9, and 11-16 are pending in the application. Claims 1, and 8-9 are amended.
Response to Arguments
Applicant’s arguments with respect to the rejections of claims 1, 3-9, and 11-16 have been fully considered. In view of the claim amendment filed, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made.
Further, regarding the new limitations recited in claims 1, and 8-9, it is submitted that they are properly addressed by the new ground of rejection.
Furthermore, it is also submitted that all limitations in pending claims, including those not specifically argued, are properly addressed. The reason is set forth in the rejections. See claim analysis below for detail.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3-9, and 11-16 are rejected under 35 U.S.C. 103 as being unpatentable over Levin et al. (US 20200336506 A1, hereinafter, Levin) in view of Comeaux et al. (US Patent No. 10567402 B1, hereinafter Comeaux) and Givental et al. (US 20180367561 A1).
Regarding Claim 1, Levin discloses a system for updating a machine learning model (Fig. 1; security system 102; [0052]: Acquiring this feedback enables a supervised learning approach that can improve the model 124 using information that continues to be collected over time), the system comprising:
at least one memory configured to store instructions; and at least one processor configured to execute the instructions and cause the system to perform ([0026]: FIG. 1 is a diagram illustrating an example environment 100 in which a security system 102),
in response to receiving an input ([0049]-[0052]: As shown in the example graphical user interface 300 of FIG. 3, the triggered alerts that are part of an identified pattern are displayed to the security analyst… the graphical user interface 300 can be configured to present an option 304 for the security analyst to provide feedback indicating whether (i) the predicted next alert has been correctly or incorrectly determined),
determining whether the input is a result list request for a scenario ([0050]: Similar to the already triggered alerts, information associated with the predicted next alert can also be displayed) or feedback, the feedback being from an analyst who has reviewed an alert ([0052]: In various examples, the graphical user interface 300 can be configured to present an option 304 for the security analyst to provide feedback… For example, upon a cursory review of the displayed information and/or a deeper investigation, a security analyst can provide an indication, via a selection of the thumbs-up option or a selection of the thumbs-down option, of whether the next alert determination module 118 correctly grouped the next predicted alert with the pattern of triggered alerts).
However, Levin does not explicitly teach “in response to the input being the result list request for the scenario, generating a result list for the scenario, the result list for the scenario including a list of alerts with corresponding scores and a first set of features, and in response to the input being the feedback identifying, in the feedback, the alert, a model score, a categorization, and a most influential feature of the first set of features, the categorization being a binary indication of whether the alert is suspicious and the most influential feature being identified by the analyst as a feature directing the categorization by the analyst, determining a scenario based on the alert, identifying a first model of a set of models corresponding to the scenario, the model score being calculated by the first model, and updating the first model based on categorization and the most influential feature.”
On the other hand, in the same field of endeavor, Comeaux teaches
in response to the input being the result list request for the scenario, generating a result list for the scenario (Figs. 2-3; [Col. 30, line 65- Col. 31, line 43]: In a next step 211, upon identifying an existing integrated alert… The security server… publishes into software services and the integrated alert database, at step 213… An analyst computer GUI may receive integrated alerts that are related to a particular subject matter; [Col. 31, line 20- 43]: Based on a risk score calculated for integrated alerts, the analyst computer presents an analyst with the integrated alert record to address next), the result list for the scenario including a list of alerts with corresponding scores (Fig. 1; [Col 18, lines 1-5]: The security server 101 or a server hosting the integrated alert database 104 may sort the integrated alerts according to the risk score, such that the integrated alerts may be presented on a graphical user interface (GUI) of an analyst computer 107 in order of priority as indicated by the relative risk scores) and a first set of features ([Col. 30, line 67- Col. 31, line 2]: the security server may update the integrated alert to include data fields from the incoming alert element), and
in response to the input being the feedback ([Col. 25, lines 9-38]: Software executed by the analyst computer 107 permits an analyst to select an integrated alert from the integrated alert database 104 and then review or update data stored in the database record for the selected integrated alert) identifying in the feedback, the alert ([Col. 26, lines 29-49]: the security server 101 may transmit an alert to an analyst computer 107 identifying the unique device IP address and/or device IDs that failed the acceptability threshold of risk score), a model score ([Col. 13, lines 22-25]: The security server 101 may generate a risk score for the integrated alerts), a categorization ([Col. 15, lines 23 - 43]: For instance, when the data fields of the alert elements underlying the particular integrated alert correspond to the remote network logon logs of the customer for suspicious access attempts, the security server 101 may apply a fraud probability score based rule to review and flag that particular integrated alert; [Col. 26, lines 9-49]: In some implementations, an analyst computer 107 may have a GUI that allows an analyst to mark or “tag” an integrated alert or alert element), and a most influential feature of the first set of features ([Col. 6, line 49 - Col. 7, line 18]: The computer-implemented method may further include identifying, by the computer, a type of threat for the integrated alert for each respective integrated alert based upon a set of model attributes indicating a potential fraud scenario… according to the most likely related fraud scenario), the categorization being a binary indication of whether the alert is suspicious ([Col. 15, lines 23 - 43]: For instance, when the data fields of the alert elements underlying the particular integrated alert correspond to the remote network logon logs of the customer for suspicious access attempts, the security server 101 may apply a fraud probability score based rule to review and flag that particular integrated alert) and the most influential feature being identified by the analyst as a feature directing the categorization by the analyst ([Col. 2, lines 58-61]: Analyst computers may… present these integrated alerts to be addressed by an analyst according to the priority level of the respective integrated alerts… In response, the analyst queue may be adjusted to reflect the updated risk scores of the integrated alerts; [Col. 2, lines 45-55]: alert elements containing various data fields, indicating threats of fraud or attempts to penetrate an enterprise network, in order to determine whether the alert elements contain attributes matching attributes of one or more scenarios.
[This is nonfunctional descriptive material describing the data elements of the alert]), and
determining a scenario based on the alert (Fig. 5; [Col. 34, lines 4-8]: The security server then determine a scenario from the set of one or more scenario attribute models that is matched with the one or more alert elements received from the one or more alert-generating systems),
identifying a first model of a set of models corresponding to the scenario (Fig. 5; [Col. 34, lines 1-4]: the security server may match attributes of the one or more alert elements received from the one or more alert-generating systems with a set of one or more scenario attribute models),
Additionally, Givental teaches the model score being calculated by the first model ([0056]: Information from the model is summarized for the SOC analyst, typically in the form of a reified value, referred to herein as a threat disposition score (TDS). Preferably, the TDS is enabled by a set of one or more supervised machine learning (ML) algorithms [Nonfunctional descriptive material describing the score]),
updating the first model based on the feedback categorization and the most influential feature (Fig. 5; [0056]: Without limitation, preferably the ML algorithm(s) create the prediction model 518 by taking into account… what action the SOC analyst took on an alert (e.g., escalation, closing, holding for further analysis, etc.), any feedback on alert handling (e.g., from L2 or L3 analysts based on the L1 analyst action), as well as a variety of attributes regarding the nature of the alert itself. The system then continuously learns (e.g., from new inputs) to improve and update its training model 518 on a regular basis… this valuable feedback is provided to the machine learning and reflected in an updated prediction model, thereby further improving the accuracy of the predicted alert disposition as indicated by the TDS [the feedback categorization and the most influential feature correspond to a variety of attributes regarding the nature of the alert itself]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teaching of Levin to incorporate the teachings of Comeaux and Givental to include, in response to the input being a result list request for a scenario, generating a result list for the scenario, and in response to the input being feedback, determining a scenario based on the alert, identifying a model of a set of models corresponding to the scenario, and updating the model based on the feedback.
The motivation for doing so would be to update the machine learning model based on updated feedback data, as recognized by Comeaux ([Col. 3, line 65-Col. 4, line 1]: The computer is further configured to iteratively update the first learning algorithm dataset based on updated data associated with the set of one or more scenario attribute models) and to enhance threat disposition analysis, as recognized by Givental ([Abstract] of Givental : An enhanced threat disposition analysis technique is provided).
Regarding Claim 3, the combined teachings of Levin, Comeaux, and Givental disclose the system of claim 1.
Comeaux further teaches wherein the generating the result list for the scenario includes obtaining a set of alerts stored in an alert database for the scenario ([Abstract]: Analyst computers may query and fetch integrated alerts from an integrate alert database, and then present the integrate alerts to be addressed by an analyst according to the priority level of the respective integrated alerts);
selecting a model from a model database for the scenario (Fig. 5; [Col. 34, lines 1-4]: the security server may match attributes of the one or more alert elements received from the one or more alert-generating systems with a set of one or more scenario attribute models);
identifying a set of features from a features database for the scenario (Fig. 5; [Col. 34, lines 1-4]: The scenario from the set of one or more scenario attribute models may identify a particular type of fraud or attack);
for each alert of the obtained set of alerts, retrieving parameters from a parameter database corresponding to a user identifier of the alert (Fig. 5; [Col. 34, lines 32-34]: In a next step 506, using the alert elements stored in the alert element database, the security server may generate integrated alerts);
inputting the parameters and the identified set of features into the selected model ([Col. 34, lines 55-57]: The first learning algorithm may receive an input of a first learning algorithm dataset);
determining, with the selected model, a score for the alert based on the parameters and the identified set of features ([Col. 34, lines 53-60]: The security server may generate a first learning algorithm configured to determine a risk associated with each of the set of one or more alert elements);
assigning a weight to each feature of the identified set of features based on how influential the feature is to the scenario (Fig. 2; [Col. 30, lines 33-47]: The security server then adjusts the risk score of the alert element according to priority weigh… The priority weight may be determined based on a type and nature of threat or a time-sensitive threat/customer-sensitive nature of the potential threat);
dividing the identified set of features into a first subset of features and a second subset of features (Fig. 3; [Col. 31, lines 36-43]: In some implementations, the integrated alerts may be stored into dedicated databases or sub-databases of the integrated alert database 300),
the first subset of features being more influential on the determined score for the alert than the second subset of features based on the assigned weights ([Col. 31, lines 7-21]: FIG. 3 shows a scenario example of movement of integrated alerts from an integrated alert database 300 in order to be addressed by an analyst… . Based on a risk score calculated for integrated alerts, the analyst computer presents an analyst with the integrated alert record to address next; [Col. 33, lines 1-11]: During operation, in the illustrated example, a security server or other server of a system executes an algorithm on an integrated alert (for example, associated with debit card fraud transaction) to determine a priority based on the integrated alert relative risk score. See also [Col. 5, lines 60-66])
the first subset of features and the second subset of features being mutually exclusive ([Col. 31, lines 44-58]: For instance, in the illustrated example, there are six integrated alert queues in sub-databases of the integrated alert database 300; and
adding the alert, the determined score, and the first subset of features to the result list ([Col. 30, lines 6-10]: Upon generating the alert element, the alert-generating system may also generate a notification message to be transmitted to the security server indicating the details of the alert element. The notification may be in any number of data formats).
Regarding Claim 4, the combined teachings of Levin, Comeaux, and Givental disclose the system of claim 3.
Comeaux further teaches wherein the identified set of features represents features used by the selected model to score an alert (Fig. 2; [Col. 30, lines 33-39]: In a next step 203, the security server generates an initial risk score. When generating a new integrated alert, the security server may generate the initial risk score based on one or more incoming alert elements that are associated with a customer identifier of a customer. Based on the data fields of the integrated alerts, the security server may determine a risk score).
Regarding Claim 5, the combined teachings of Levin, Comeaux, and Givental disclose the system of claim 3.
Comeaux further teaches wherein each alert of the obtained set of alerts includes a transaction identifier and a threshold exceeded ([Col. 2-Col. 3]: In one embodiment, a computer-implemented method may include receiving, by a computer, a set of one or more alert elements containing a customer identifier from one or more alert-generating systems; [Col. 11, lines 5-11]: The computer-implemented method may further include determining, by the computer, a probability score for likelihood of fraud in each of the one or more session records based on the threshold value for each of the number of session attributes).
Regarding Claim 6, the combined teachings of Levin, Comeaux, and Givental disclose the system of claim 3.
Comeaux further teaches wherein the parameter database includes, for the user identifier, an account type, a total account amount, a trading frequency, and an average trading amount ([Col. 16, lines 10-12]: the security server 101 may determine total financial assets of the customer stored in the system database 102; [Col. 29, line 66-Col. 30, line 6]: For example, a third-party payment server may generate an alert element containing data elements related to money transfers or transaction requests, such as account identifiers, customer identifiers, a timestamp, and the amount of money at issue).
Regarding Claim 7, the combined teachings of Levin, Comeaux, and Givental disclose the system of claim 3.
Comeaux further teaches wherein the generating the result list for the scenario further includes sorting the result list based on the score of each alert of the obtained set of alerts (Fig. 1; [Col 18, lines 1-5]: The security server 101 or a server hosting the integrated alert database 104 may sort the integrated alerts according to the risk score, such that the integrated alerts may be presented on a graphical user interface (GUI) of an analyst computer 107 in order of priority as indicated by the relative risk scores).
Regarding Claim 8, the combined teachings of Levin, Comeaux, and Givental disclose the system of claim 1.
Comeaux further teaches wherein the at least one memory stores a result list database and the system is further caused to perform storing the result list in the result list database ([Col. 18, lines 8-12]: The type of threat identified and each of the integrated alerts is then stored into a sub-database of the integrated database 104 according to the potential fraud scenario and sorted according to the relative risk score within the sub-database; Fig. 2; [Col. 30-31]: The security server may further update the integrated alert risk score based upon the risk scores and policy weights for the aggregated alert elements underlying the integrated alert, and publishes into software services and the integrated alert database, at step 213).
Regarding Claim 9, Levin discloses a method for updating a machine learning model ([0052]: Acquiring this feedback enables a supervised learning approach that can improve the model 124 using information that continues to be collected over time), the method comprising,
in response to receiving an input ([0049]-[0052]: As shown in the example graphical user interface 300 of FIG. 3, the triggered alerts that are part of an identified pattern are displayed to the security analyst… the graphical user interface 300 can be configured to present an option 304 for the security analyst to provide feedback indicating whether (i) the predicted next alert has been correctly or incorrectly determined):
determining whether the input is a result list request for a scenario ([0050]: Similar to the already triggered alerts, information associated with the predicted next alert can also be displayed) or feedback, the feedback being from an analyst who has reviewed an alert ([0052]: In various examples, the graphical user interface 300 can be configured to present an option 304 for the security analyst to provide feedback indicating whether (i) the predicted next alert has been correctly or incorrectly determined… For example, upon a cursory review of the displayed information and/or a deeper investigation, a security analyst can provide an indication, via a selection of the thumbs-up option or a selection of the thumbs-down option, of whether the next alert determination module 118 correctly grouped the next predicted alert with the pattern of triggered alerts),
However, Levin does not explicitly teach “in response to the input being the result list request for the scenario, generating a result list for the scenario, the result list for the scenario including a list of alerts with corresponding scores and a first set of features, and in response to the input being the feedback identifying, in the feedback, the alert, a model score, a categorization, and a most influential feature of the first set of features, the categorization being a binary indication of whether the alert is suspicious and the most influential feature being identified by the analyst as a feature directing the categorization by the analyst, determining a scenario based on the alert, identifying a first model of a set of models corresponding to the scenario, the model score being calculated by the first model, and updating the first model based on categorization and the most influential feature.”
On the other hand, in the same field of endeavor, Comeaux teaches
in response to the input being the result list request for the scenario, generating a result list for the scenario (Figs. 2-3; [Col. 30, line 65- Col. 31, line 43]: In a next step 211, upon identifying an existing integrated alert… The security server… publishes into software services and the integrated alert database, at step 213… An analyst computer GUI may receive integrated alerts that are related to a particular subject matter; [Col. 31, line 20- 43]: Based on a risk score calculated for integrated alerts, the analyst computer presents an analyst with the integrated alert record to address next),
the result list for the scenario including a list of alerts with corresponding scores (Fig. 1; [Col 18, lines 1-5]: The security server 101 or a server hosting the integrated alert database 104 may sort the integrated alerts according to the risk score, such that the integrated alerts may be presented on a graphical user interface (GUI) of an analyst computer 107 in order of priority as indicated by the relative risk scores) and a first set of features ([Col. 30, line 67- Col. 31, line 2]: the security server may update the integrated alert to include data fields from the incoming alert element), and
in response to the input being the feedback ([Col. 25, lines 9-38]: Software executed by the analyst computer 107 permits an analyst to select an integrated alert from the integrated alert database 104 and then review or update data stored in the database record for the selected integrated alert) identifying in the feedback, the alert ([Col. 26, lines 29-49]: the security server 101 may transmit an alert to an analyst computer 107 identifying the unique device IP address and/or device IDs that failed the acceptability threshold of risk score), a model score ([Col. 13, lines 22-25]: The security server 101 may generate a risk score for the integrated alerts), a categorization ([Col. 15, lines 23 - 43]: For instance, when the data fields of the alert elements underlying the particular integrated alert correspond to the remote network logon logs of the customer for suspicious access attempts, the security server 101 may apply a fraud probability score based rule to review and flag that particular integrated alert; [Col. 26, lines 9-49]: In some implementations, an analyst computer 107 may have a GUI that allows an analyst to mark or “tag” an integrated alert or alert element), and a most influential feature of the first set of features ([Col. 6, line 49 - Col. 7, line 18]: The computer-implemented method may further include identifying, by the computer, a type of threat for the integrated alert for each respective integrated alert based upon a set of model attributes indicating a potential fraud scenario… according to the most likely related fraud scenario), the categorization being a binary indication of whether the alert is suspicious ([Col. 15, lines 23 - 43]: For instance, when the data fields of the alert elements underlying the particular integrated alert correspond to the remote network logon logs of the customer for suspicious access attempts, the security server 101 may apply a fraud probability score based rule to review and flag that particular integrated alert) and the most influential feature being identified by the analyst as a feature directing the categorization by the analyst ([Col. 2, lines 58-61]: Analyst computers may… present these integrated alerts to be addressed by an analyst according to the priority level of the respective integrated alerts… In response, the analyst queue may be adjusted to reflect the updated risk scores of the integrated alerts; [Col. 2, lines 45-55]: alert elements containing various data fields, indicating threats of fraud or attempts to penetrate an enterprise network, in order to determine whether the alert elements contain attributes matching attributes of one or more scenarios.
[This is nonfunctional descriptive material describing the data elements of the alert]), and
determining a scenario based on the alert (Fig. 5; [Col. 34, lines 4-8]: The security server then determine a scenario from the set of one or more scenario attribute models that is matched with the one or more alert elements received from the one or more alert-generating systems),
identifying a first model of a set of models corresponding to the scenario (Fig. 5; [Col. 34, lines 1-4]: the security server may match attributes of the one or more alert elements received from the one or more alert-generating systems with a set of one or more scenario attribute models),
Additionally, Givental teaches the model score being calculated by the first model ([0056]: Information from the model is summarized for the SOC analyst, typically in the form of a reified value, referred to herein as a threat disposition score (TDS). Preferably, the TDS is enabled by a set of one or more supervised machine learning (ML) algorithms [Nonfunctional descriptive material describing the score]),
updating the first model based on the feedback categorization and the most influential feature (Fig. 5; [0056]: Without limitation, preferably the ML algorithm(s) create the prediction model 518 by taking into account… what action the SOC analyst took on an alert (e.g., escalation, closing, holding for further analysis, etc.), any feedback on alert handling (e.g., from L2 or L3 analysts based on the L1 analyst action), as well as a variety of attributes regarding the nature of the alert itself. The system then continuously learns (e.g., from new inputs) to improve and update its training model 518 on a regular basis… this valuable feedback is provided to the machine learning and reflected in an updated prediction model, thereby further improving the accuracy of the predicted alert disposition as indicated by the TDS [the feedback categorization and the most influential feature correspond to a variety of attributes regarding the nature of the alert itself]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the teaching of Levin to incorporate the teachings of Comeaux and Givental to include, in response to the input being a result list request for a scenario, generating a result list for the scenario, and in response to the input being feedback, determining a scenario based on the alert, identifying a model of a set of models corresponding to the scenario, and updating the model based on the feedback.
The motivation for doing so would be to update the machine learning model based on updated feedback data, as recognized by Comeaux ([Col. 3, line 65-Col. 4, line 1]: The computer is further configured to iteratively update the first learning algorithm dataset based on updated data associated with the set of one or more scenario attribute models) and to enhance threat disposition analysis, as recognized by Givental ([Abstract] of Givental: An enhanced threat disposition analysis technique is provided).
Regarding Claim 11, the combined teachings of Levin, Comeaux, and Givental disclose the method of claim 9.
Comeaux further teaches wherein the generating the result list for the scenario includes obtaining a set of alerts stored in an alert database for the scenario ([Abstract]: Analyst computers may query and fetch integrated alerts from an integrate alert database, and then present the integrate alerts to be addressed by an analyst according to the priority level of the respective integrated alerts);
selecting a model from a model database for the scenario (Fig. 5; [Col. 34, lines 1-4]: the security server may match attributes of the one or more alert elements received from the one or more alert-generating systems with a set of one or more scenario attribute models);
identifying a set of features from a features database for the scenario (Fig. 5; [Col. 34, lines 1-4]: The scenario from the set of one or more scenario attribute models may identify a particular type of fraud or attack);
for each alert of the obtained set of alerts, retrieving parameters from a parameter database corresponding to a user identifier of the alert (Fig. 5; [Col. 34, lines 32-34]: In a next step 506, using the alert elements stored in the alert element database, the security server may generate integrated alerts);
inputting the parameters and the identified set of features into the selected model ([Col. 34, lines 55-57]: The first learning algorithm may receive an input of a first learning algorithm dataset);
determining, with the selected model, a score for the alert based on the parameters and the identified set of features ([Col. 34, lines 53-60]: The security server may generate a first learning algorithm configured to determine a risk associated with each of the set of one or more alert elements);
assigning a weight to each feature of the identified set of features based on how influential the feature is to the scenario (Fig. 2; [Col. 30, lines 33-47]: The security server then adjusts the risk score of the alert element according to priority weigh… The priority weight may be determined based on a type and nature of threat or a time-sensitive threat/customer-sensitive nature of the potential threat);
dividing the identified set of features into a first subset of features and a second subset of features(Fig. 3; [Col. 31, lines 36-43]: In some implementations, the integrated alerts may be stored into dedicated databases or sub-databases of the integrated alert database 300),
the first subset of features being more influential on the determined score for the alert than the second subset of features based on the assigned weights ([Col. 31, lines 7-21]: FIG. 3 shows a scenario example of movement of integrated alerts from an integrated alert database 300 in order to be addressed by an analyst… . Based on a risk score calculated for integrated alerts, the analyst computer presents an analyst with the integrated alert record to address next; [Col. 33, lines 1-11]: During operation, in the illustrated example, a security server or other server of a system executes an algorithm on an integrated alert (for example, associated with debit card fraud transaction) to determine a priority based on the integrated alert relative risk score. See also [Col. 5, lines 60-66]),
the first subset of features and the second subset of features being mutually exclusive ([Col. 31, lines 44-58]: For instance, in the illustrated example, there are six integrated alert queues in sub-databases of the integrated alert database 300); and
adding the alert, the determined score, and the first subset of features to the result list ([Col. 30, lines 6-10]: Upon generating the alert element, the alert-generating system may also generate a notification message to be transmitted to the security server indicating the details of the alert element. The notification may be in any number of data formats).
Regarding Claim 12, the combined teachings of Levin, Comeaux, and Givental disclose the method of claim 11.
Comeaux further teaches wherein the identified set of features represents features used by the selected model to score an alert (Fig. 2; [Col. 30, lines 33-39]: In a next step 203, the security server generates an initial risk score. When generating a new integrated alert, the security server may generate the initial risk score based on one or more incoming alert elements that are associated with a customer identifier of a customer. Based on the data fields of the integrated alerts, the security server may determine a risk score).
Regarding Claim 13, the combined teachings of Levin, Comeaux, and Givental disclose the method of claim 11.
Comeaux further teaches wherein each alert of the obtained set of alerts includes a transaction identifier and a threshold exceeded ([Col. 2-Col. 3]: In one embodiment, a computer-implemented method may include receiving, by a computer, a set of one or more alert elements containing a customer identifier from one or more alert-generating systems; [Col. 11, lines 5-11]: The computer-implemented method may further include determining, by the computer, a probability score for likelihood of fraud in each of the one or more session records based on the threshold value for each of the number of session attributes).
Regarding Claim 14, the combined teachings of Levin, Comeaux, and Givental disclose the method of claim 11.
Comeaux further teaches wherein the parameter database includes, for the user identifier, an account type, a total account amount, a trading frequency, and an average trading amount ([Col. 16, lines 10-12]: the security server 101 may determine total financial assets of the customer stored in the system database 102; [Col. 29, line 66-Col. 30, line 6]: For example, a third-party payment server may generate an alert element containing data elements related to money transfers or transaction requests, such as account identifiers, customer identifiers, a timestamp, and the amount of money at issue).
Regarding Claim 15, the combined teachings of Levin, Comeaux, and Givental disclose the method of claim 11.
Comeaux further teaches wherein the generating the result list for the scenario further includes sorting the result list based on the score of each alert of the obtained set of alerts (Fig. 1; [Col 18, lines 1-5]: The security server 101 or a server hosting the integrated alert database 104 may sort the integrated alerts according to the risk score, such that the integrated alerts may be presented on a graphical user interface (GUI) of an analyst computer 107 in order of priority as indicated by the relative risk scores).
Regarding Claim 16, the combined teachings of Levin, Comeaux, and Givental disclose the method of claim 9.
Comeaux further teaches further comprising storing the result list in a result list database ([Col. 18, lines 8-12]: The type of threat identified and each of the integrated alerts is then stored into a sub-database of the integrated database 104 according to the potential fraud scenario and sorted according to the relative risk score within the sub-database; Fig. 2; [Col. 30-31]: The security server may further update the integrated alert risk score based upon the risk scores and policy weights for the aggregated alert elements underlying the integrated alert, and publishes into software services and the integrated alert database, at step 213).
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 extension fee 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 SHIRLEY D. HICKS whose telephone number is (571)272-3304. The examiner can normally be reached Mon - Fri 7:30 - 4:00.
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, Charles Rones can be reached on (571) 272-4085. 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.
/S D H/Examiner, Art Unit 2168
/CHARLES RONES/Supervisory Patent Examiner, Art Unit 2168
Prosecution Insights