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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible
for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been
timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR
1.114. Applicant’s submission filed on 04/26/2026 has been entered.
Claims 1, 11 and 18 are independent claims. The applicant has amended claims 1, 6, 11, 16, 18 and 19. Claims 1-2 and 4-21 have been examined and are pending. This Action is made Non-FINAL.
Response to Arguments
Applicants’ arguments with respect to claim(s) 1, 6, 11, 16, 18 and 19 in the instant Amendment, filed on 04/26/2026, with respect to limitations listed below, have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
The Examiner respectfully suggests that the claim be further amended; details in the specification be incorporated, to distinguish the claimed invention over prior art of record. Should the Applicant desire an interview to further clarify the claim interpretation/rejections, please contact the Examiner at (571) 272-1531 to schedule an interview.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 18 and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim (US 20180109947 A1), in view of Sprague (US 20220021664 A1), and in further view of Banes (US 20030182584 A1).
Regarding Claim 1
Kim discloses:
A computer-implemented method comprising:
receiving, at a user device, a key request for a cryptographic key assigned to the user device (Kim: ¶¶190–192, 210: first electronic device receives an authentication-key registration request from the external device; authentication/key-registration processing is initiated in response to the request);
receiving, from the user device, data encrypted according to the cryptographic key assigned to the user device requesting to use one or more system resources (Kim: ¶250: first electronic device encrypts/signs authentication information using its private key and transmits the authentication information to the second electronic device; ¶¶252, 283: successful authentication permits logon or performance of the requested function);
verifying an authenticity of the cryptographic key for the user device corresponding to confirming the identity of the user device or the user (Kim: ¶¶148, 251, 280: second electronic device identifies/verifies the signature of received authentication information using the corresponding public key and determines whether the authentication information is valid);
Kim does not expressly disclose providing the cryptographic key to the user device via a secure communication channel for use in confirming an identity of the user device or user to a user risk analyzer executing on a computing platform, or determining a security risk score in response to successful verification and using that score to control access. However, Sprague discloses secure device identity verification and trust based access control. Sprague discloses that a device identity agent establishes an SSL session with the device identity server over a WebSocket connection, sends a key to the server, and, when the keys match, the server issues a unique device identifier, such as a cryptographic nonce, to the device identity agent over the secure connection (Sprague: ¶139). Sprague further discloses that a device identifier may be implemented using a generated cryptographic key pair stored on the device (Sprague: ¶114), and that the device identity server uses device identification information to confirm the identity of the device and calculate a trust score (Sprague: ¶¶43, 74, 81). Sprague further discloses that, once the device identity server confirms the identity of the device, the server returns the device ID and a calculated trust score (Sprague: ¶81), and that device identification information is collected and verified before the trust score is calculated or adjusted (Sprague: ¶123). The trust score represents the trustworthiness of the requesting device and is provided to a third-party service provider for determining whether access should be permitted (Sprague: ¶¶43–44, 86–89, 126, 136). Sprague further discloses comparing the trust score to a trust score threshold and granting access when the threshold is satisfied, while withholding access, requiring additional verification, or terminating the session when the threshold is not satisfied (Sprague: ¶¶44, 88–89, 126, 131, 138).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Kim to employ Sprague's secure SSL/WebSocket device identification technique and, following successful cryptographic authentication in Kim, evaluate the authenticated device using Sprague's trust score and threshold before permitting access. The motivation to combine would have been to improve security by permitting access only when the requesting device is both successfully authenticated and satisfies an acceptable security threshold (Sprague: ¶¶43–44, 82, 138), while protecting device identification information during communication using Sprague's secure SSL/WebSocket connection (Sprague: ¶139).
Kim as modified by Sprague does not expressly disclose that the cryptographic key is stored at a location that is user controlled and unknown to the system. However, Banes discloses storing a private cryptographic key on removable computer-readable media under the user's control. Banes discloses storing the public key in a password file on the computer system while storing the private key on removable media (Banes: ¶36); prompting the user to select the removable media drive on which the private key is stored (Banes: ¶47, block 406); writing the private key to the removable medium, deleting any remaining copy of the private key from the computer system or elsewhere, and permitting the user thereafter to store the medium in a safe, secure location (Banes: ¶49, blocks 414–416); and, when the private key is later needed, having the user identify the drive containing the removable medium (Banes: ¶52, block 502; see also ¶¶10, 26).
It would have been obvious to one having ordinary skill in the art to further modify Kim as modified by Sprague according to Banes so that the user side cryptographic key is maintained at a location controlled by the user and information identifying that storage location is not communicated to or retained by the remote computing platform. The motivation to combine would have been to obtain Banes' security benefit of separating the private key from the computer system and deleting other copies of the private key, thereby reducing the ability of an unauthorized party having access to the computer system to discover and misuse the private key (Banes: ¶¶13, 49). Further, because Kim authenticates the user/device remotely using the corresponding public key (Kim: ¶¶251, 280), knowledge of the user side private key storage location is unnecessary to perform the remote authentication. Thus, maintaining the storage location information only on the user side would preserve Banes's separation technique without changing Kim and Sprague's authentication or trust scoring functions.
Regarding Claim 2
Kim discloses the computer-implemented method of claim 1, further comprising assigning the cryptographic key to the user device (Kim: ¶¶184–186: after successful verification of authentication information from the first electronic device, the second electronic device generates an authentication key, e.g., a symmetric key, for authentication between the first and second electronic devices, stores the key, and maps the key to device information of the first electronic device; ¶222: the second electronic device registers and manages the first electronic device as a companion device based on the symmetric key corresponding to the first electronic device).
Regarding Claim 18
Kim discloses a system comprising one or more computing platforms configured to:
receive a key request for a cryptographic key assigned to a user device (Kim: ¶¶190–192: the first electronic device receives an authentication key registration request from the external device and initiates authentication/key registration processing in response to the request);
generate a graphical user interface (GUI),
receive data encrypted according to the cryptographic key assigned to the user device requesting to use one or more system resources (Kim: ¶250: the first electronic device encrypts/signs authentication information using its private key and transmits the authentication information to the second electronic device; ¶¶252, 283: successful authentication permits logon or performance of the requested function);
verify an authenticity of the cryptographic key for the user device corresponding to confirming the identity of the user device or the user (Kim: ¶¶148, 251, 280: the second electronic device verifies the signature/authentication information using the corresponding public key and determines whether the received authentication information is valid);
Kim does not expressly disclose providing the cryptographic key to the user device via a secure communication channel through the GUI, storing the cryptographic key at a location that is user controlled and unknown to the system, or determining a security risk score in response to successful verification and using the score to control access. However, Sprague discloses secure device identity verification and trust based access control. Sprague discloses that a device identity agent establishes an SSL session with a device identity server over a WebSocket connection, sends a key to the server, and when the keys match, the server issues a unique device identifier to the device identity agent over the secure connection (Sprague: ¶139). Sprague further discloses that a device identifier may be implemented using a generated cryptographic key pair stored on the device (Sprague: ¶114) and that the device identity server confirms device identity and calculates a trust score (Sprague: ¶¶43, 74, 81). Once the device identity server confirms the identity of the device the server returns the device ID and calculated trust score (Sprague: ¶81) and device identification information is collected and verified before the trust score is calculated or adjusted (Sprague: ¶123). Sprague further discloses providing the trust score to a third party service provider and comparing the score with a threshold to determine whether access is permitted (Sprague: ¶¶43–44, 86–89, 126, 131, 136, 138).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Kim to employ Sprague's secure SSL/WebSocket device identification technique and, following successful cryptographic authentication in Kim, evaluate the authenticated device using Sprague's trust score and threshold before permitting access. The motivation to combine would have been to improve security by permitting access only when the requesting device is both successfully authenticated and satisfies an acceptable security threshold (Sprague: ¶¶43–44, 82, 138), while protecting device identification information during communication using Sprague's secure SSL/WebSocket connection (Sprague: ¶139).
Kim as modified by Sprague does not expressly disclose that the cryptographic key is stored at a location that is user controlled and unknown to the system. However, Banes discloses storing a private cryptographic key on removable computer readable media under the user's control. Banes discloses storing the public key in a password file on the computer system while storing the private key on removable media (Banes: ¶36); prompting the user to select the removable media drive on which the private key is stored (Banes: ¶47, block 406); writing the private key to the removable medium, deleting any remaining copy of the private key from the computer system or elsewhere, and permitting the user thereafter to store the medium in a safe, secure location (Banes: ¶49, blocks 414–416); and, when the private key is later needed, having the user identify the drive containing the removable medium (Banes: ¶52, block 502; see also ¶¶10, 26).
It would have been obvious to one having ordinary skill in the art to further modify Kim as modified by Sprague according to Banes so that the user side cryptographic key is maintained at a location controlled by the user and information identifying that storage location is not communicated to or retained by the remote computing platform. The motivation to combine would have been to obtain Banes's security benefit of separating the private key from the computer system and deleting other copies of the private key, thereby reducing the ability of an unauthorized party having access to the computer system to discover and misuse the private key (Banes: ¶¶13, 49). Further, because Kim authenticates the user/device remotely using the corresponding public key (Kim: ¶¶251, 280), knowledge of the user side private key storage location is unnecessary to perform the remote authentication. Thus, maintaining the storage location information only on the user side would preserve Banes's separation technique without changing Kim and Sprague's authentication or trust scoring functions.
Regarding Claim 21
Kim as modified by Sprague and Banes discloses the limitations of claim 1. Kim further discloses generating a graphical user interface (GUI) at the user device in connection with authentication key registration and user/device authentication (Kim: ¶¶190–192: the electronic device receives an authentication key registration request and displays a GUI/UI for device or user authentication; ¶¶184–185: following successful authentication, an authentication key, e.g., a symmetric key, is generated and stored).
Claims 4 is rejected under 35 U.S.C. 103 as being unpatentable over Kim in view of Sprague and Banes as applied to claim 1 above, and further in view of Johnson (US 2005/0038994 A1).
Regarding Claim 4
Kim as modified by Sprague and Banes discloses the limitations of claim 1. However, the combination does not expressly disclose wherein the cryptographic key is verified as authentic in response to a successful decryption of the encrypted data. Johnson discloses decrypting an encrypted authentication sequence using a network identifier as a decryption key and determining whether the decryption was successful by determining whether the decrypted authentication sequence is valid (Johnson: ¶27: encrypted authentication sequence is decrypted using the currently acquired network identifier as a decryption key, and successful decryption is determined by validating the decrypted authentication sequence; ¶35: the network identifier is used as the key to decrypt the encrypted authentication sequence, after which the system determines whether the decrypted authentication sequence is valid).
It would have been obvious to one having ordinary skill in the art to modify Kim as modified by Sprague and Banes according to Johnson so that authenticity of the cryptographic key is confirmed based on successful decryption of the encrypted authentication data, because Johnson teaches using successful decryption yielding valid authentication information as confirmation that the decryption key corresponds to the encrypted authentication sequence. The motivation to combine would have been to provide an additional cryptographic validity check before permitting authenticated access.
Claims 5-7, 9, 11, 12, 14 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim in view of Sprague and Banes as applied to claim 1, 11 and 18 above, and in further view of Badana (US 11,743,298 B2).
Regarding Claim 5
Kim as modified by Sprague and Banes discloses the limitations of claim 1. However, the combination does not expressly disclose wherein the level of security risk is determined based on user role information for the user, user behavior information for the user, and system log information. However, Badana discloses determining security risk based on user profile information, user behavior information, and logged user activity. Badana discloses that ML generated priority levels are based on the user profile of the end user (Badana: col. 5, ll. 21–24: “The priority levels are ML generated based on the user profile of the end user 106”) and that aggregate risk further considers the user profile in determining risk (Badana: col. 5, ll. 63–65). Badana further discloses that authorization is determined based on network traffic and the user profile (Badana: col. 11, ll. 18–22: “Based on the analysis of the network traffic and the user profile, it is identified in the analyzer 322 whether the third party content is authorized”), and that ML generated risk scores influence authorization (Badana: col. 11, ll. 25–27). Badana further discloses monitoring and analyzing user activities, including browsing, searching, streaming, downloading, and application usage (Badana: col. 19, ll. 40–42: “user activities of the end user 106 performed on the client device 102 are monitored and analyzed by the analyzer 322”; col. 19, ll. 44–46: “The user activities may include browsing, searching, streaming, downloading, or using applications”), and using machine learning to identify patterns in such activities (Badana: col. 19, ll. 46–49). Badana also expressly discloses that user behavior analysis is performed based on the third-party content from the browsing history of the end user (Badana: col. 20, ll. 11–14). Badana further discloses system log information in the form of browsing history and user activity logs. The browsing history log stores user activities and provides the user activities to the analyzer (Badana: col. 19, ll. 42–44). Badana further discloses that the browsing history log is acquired from user logs of the client device (Badana: col. 13, ll. 57–60) and includes third-party content, including websites, applications, and content streaming, previously accessed by the end user (Badana: col. 13, ll. 60–67).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Kim as modified by Sprague and Banes according to Badana so that the security risk determination considers user profile information, user behavior information, and system log information. Badana expressly teaches that user profile information influences risk and authorization decisions, while user behavioral information and browsing history logs are analyzed to determine risk. It would have been also obvious to include user role information as part of the user profile information considered in determining risk because the user's role is an access related user attribute useful for distinguishing the permissions and expected activities of different users. The motivation to combine would have been to improve the accuracy of the risk determination by considering not only device authentication, but also characteristics of the user, the user's behavior, and logged historical activity.
Regarding Claim 6
Regarding claim 6, Kim as modified by Sprague and Banes discloses the limitations of claim 1. However, the combination does not expressly disclose wherein a machine learning (ML) model is used to determine the level of security risk posed by the request and output the risk score, wherein the ML model determines the risk score based on user role information, user behavior information, and system log information. However, Badana discloses using ML models to determine a risk score associated with a request. Badana discloses determining a risk score based on a policy using ML models, wherein the ML models analyze user activities from network traffic for determination of the risk score, and the resulting risk score is compared with a threshold to authorize the request (Badana: col. 2, ll. 28–37). Badana further discloses that user activities of the end user are monitored and analyzed by an analyzer, the browsing history log stores those user activities and provides them to the analyzer, and ML algorithms analyze the user activities to identify behavioral patterns (Badana: col. 19, ll. 40–49). Badana further expressly states that user activities are inputs to ML models used as datasets for training and that ML models generate user profile scores based on user activities (Badana: col. 20, ll. 37–61). Thus, Badana teaches using an ML model to determine a risk/profile score based on user behavioral information and logged user activity. Badana also discloses that risk determinations consider the user profile and that ML generated priority levels are based on the user profile of the end user (Badana: col. 5, ll. 21–24, 63–65). It would have been obvious to include user role information as part of the user profile information supplied to the ML based risk determination because the user's role is an access related user attribute useful for distinguishing permissions and expected behavior among different users.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Kim as modified by Sprague and Banes according to Badana so that an ML model determines the security risk score based on user profile information, user behavior information, and system log information, including user role information as part of the user profile. The motivation to combine would have been to improve the accuracy of the risk determination by allowing the ML model to evaluate not only the requesting device's authentication status, but also characteristics of the user, the user's historical behavior, and logged activity patterns.
Regarding Claim 7
Kim as modified by Sprague, Banes, and Badana discloses the limitations of claim 6. Badana further discloses configuring the machine learning model to determine security risk based on user profile information, user behavioral information, and logged user activity. Badana discloses that ML generated priority levels are based on the user profile of the end user and that aggregate risk further considers the user profile in determining risk (Badana: col. 5, ll. 21–24, 63–65); that authorization is determined based on network traffic and the user profile and that ML generated risk scores influence authorization (Badana: col. 11, ll. 18–27); that user activities are monitored and analyzed, including browsing, searching, streaming, downloading, and application usage, and that ML algorithms identify behavioral patterns from those activities (Badana: col. 19, ll. 40–49; col. 20, ll. 11–14); and that a browsing history log stores user activities and provides those activities to the analyzer, the log being acquired from user logs of the client device and including previously accessed websites, applications, and content (Badana: col. 13, ll. 57–67; col. 19, ll. 42–44). It would have been obvious to include user role information as part of the user profile information used by the ML model because the user's role is an access related user attribute useful for distinguishing the expected activities and permissions of different users
It would therefore have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to configure the ML model of Badana, as incorporated into Kim as modified by Sprague and Banes, to determine the level of security risk posed by the request based on user role information, user behavior information, and system log information. The motivation to combine would have been to improve the accuracy of the security risk determination by considering characteristics of the user together with the user's behavioral patterns and logged historical activity.
Regarding Claim 9
Kim as modified by Sprague, Banes, and Badana discloses the limitations of claim 6. Badana further discloses system log information characterizing application related information and/or time. Badana discloses browsing-history logs containing third-party content including websites and applications accessed by the end-user and user activities associated with those accesses (Badana: col. 13, ll. 57–67; col. 19, ll. 42–49). Badana further discloses monitoring and analyzing user activities over time and using the browsing-history information in the risk analysis (Badana: col. 19, ll. 40–49; col. 20, ll. 11–14).
It would therefore have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Kim as modified by Sprague, Banes, and Badana so that the system of information used in the risk determination characterizes application related information and/or time related information, as taught by Badana. The motivation to combine would have been to improve the accuracy of the security risk determination by incorporating logged historical information identifying the applications/content accessed by the user and the timing/history of such activity.
Regarding Claim 11
Kim discloses a system comprising:
a user device comprising a cryptographic key assigned for the user device, the user device being configured to:
receive a key request for the cryptographic key assigned to the user device (Kim: ¶¶190–192, 210: the first electronic device receives an authentication-key registration request and authentication-key registration processing is initiated in response to the request; ¶¶184–186: an authentication key, e.g., a symmetric key, is generated for authentication and is mapped to device information of the first electronic device);
generate a guided user interface (GUI) (Kim: ¶192: the first electronic device displays a GUI/UI associated with device or user authentication);
encrypt data according to the cryptographic key, the data comprising a request to use one or more system resources (Kim: ¶250: the first electronic device encrypts/signs authentication information using cryptographic information and transmits the authentication information to the second electronic device; ¶¶252, 283: following successful authentication, logon or performance of a requested function is permitted);
a server configured to:
verify an authenticity of the cryptographic key for the user device corresponding to confirming the identity of the user device or the user of the user device (Kim: ¶¶148, 251, 280: the second electronic device identifies/verifies authentication information using corresponding cryptographic information and determines whether the received authentication information is valid);
Kim does not expressly disclose that the GUI allows the user to provide the cryptographic key to the user device via a secure communication channel for use in confirming the identity of the user device or user to a user risk analyzer, that the cryptographic key is stored at a location that is user controlled and unknown to the system, or that, following successful cryptographic verification, a machine learning model outputs a security risk score that is compared with a threshold to control access. However, Sprague discloses secure device identity verification and trust based access control. Sprague discloses that a device identity agent establishes an SSL session with a device identity server over a WebSocket connection, sends cryptographic identification information to the server, and, upon successful verification, receives a unique device identifier such as a cryptographic nonce over the secure connection (Sprague: ¶139). Sprague further discloses that a device identifier may be implemented using a generated cryptographic key pair stored in a key file on the device (Sprague: ¶114), and that device identification information is used to confirm the identity of the device and calculate a trust score (Sprague: ¶¶43, 74, 81). Sprague further discloses that the device identification information is collected and verified before the trust score is calculated or adjusted (Sprague: ¶123). Sprague further discloses that the trust score represents the trustworthiness of the requesting device and is provided to a third-party service provider for determining whether access should be permitted (Sprague: ¶¶43–44, 86–89, 126, 136). Sprague further discloses comparing the trust score to a trust score threshold and permitting access when the required threshold is satisfied, while withholding access, requiring additional verification, or terminating the session when the threshold is not satisfied (Sprague: ¶¶44, 88–89, 126, 131, 138).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Kim according to Sprague so that cryptographic device identification information used to confirm the identity of the user device or user is exchanged over a secure communication channel and, following successful verification of the device-identification information, a security score is generated and compared with a threshold to determine whether access to system resources should be permitted. Sprague teaches establishing an SSL/WebSocket secure connection for exchanging cryptographic device identification information and further teaches verifying the device identity before calculating a trust score and using that score to control access. The motivation to combine would have been to protect authentication information during transmission and to supplement Kim’s cryptographic authentication with an additional security assessment before granting access to protected resources.
Banes further discloses user controlled storage of cryptographic key information. Banes discloses generating a public/private key pair and storing the private key on removable media maintained by the user and separate from the computer system (Banes: ¶¶10, 13, 36). Banes further discloses allowing the user to select the removable-media drive at which the private key will be stored (Banes: ¶47), writing the private key to the selected removable medium and deleting versions of the private key remaining on the computer system or elsewhere (Banes: ¶49), and subsequently requiring the user to select or identify the removable-media drive when the private key is required (Banes: ¶52). Thus, Banes teaches maintaining cryptographic key information at a storage location controlled by the user and separated from the computer system.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Kim according to Banes so that the user side cryptographic key storage location is controlled by the user and is not communicated to or retained by the remote authentication platform. Banes expressly teaches separating the private key from the computer system and deleting other copies in order to protect the private key (Banes: ¶¶13, 49). Kim's remote authentication process verifies received authentication information using corresponding cryptographic information (Kim: ¶¶251, 280) and therefore does not require the remote authentication platform to know the location at which the user's private key is stored. The motivation to combine would have been to reduce exposure of the user's private key while preserving Kim's remote cryptographic-authentication functionality.
Badana further discloses using a machine learning model to determine a risk score for controlling access. Badana discloses determining a risk score using ML models, wherein the ML models analyze user activity for determination of the risk score, and comparing the resulting risk score with a threshold for determining whether a data-access request is authorized (Badana: col. 2, ll. 28–37). Badana therefore teaches using an ML model to output a risk score indicative of a level of security risk and evaluating the resulting score against a risk threshold in making an access control determination.
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Kim according to Sprague, Banes, and Badana so that, after successful cryptographic authentication of the user device or user, the server evaluates the authenticated request using an ML generated security risk score, compares the risk score with a threshold, and grants or denies access according to the threshold determination, while cryptographic device identification information is communicated over a secure communication channel and the user's cryptographic key is maintained at a user controlled storage location. The motivation to combine would have been to permit access to protected system resources only when the requesting device or user has been successfully authenticated and satisfies an acceptable security risk threshold, while protecting cryptographic key information through secure communication and user controlled key storage.
Regarding Claim 12
Claim 12 is directed to a system corresponding to the computer-implemented method in claim 5. Claim 12 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Regarding Claim 14
Claim 14 is directed to a system corresponding to the computer-implemented method in claim 9. Claim 14 is similar in scope to claim 9 and is therefore rejected under similar rationale.
Regarding Claim 19
Claim 19 is directed to a system corresponding to the computer-implemented method in claim 5. Claim 19 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Claims 8, 10, 13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Kim, in view of Sprague, in view of Banes, in view of Badana, as applied to claims 6, 7 and 11 above, and further in view of Iyer (US 2018/0052994 A1).
Regarding Claim 8
Kim as modified by Sprague, Banes, and Badana discloses the limitations of claim 6. However, the combination does not expressly disclose wherein the user behavior information indicates a number of access attempts, successful and denied access requests, a time difference between requests, and a correlation with a user role. Iyer discloses monitoring suspicious user activity including failed authentications and concurrent accesses, and comparing employee behavior with an organizational peer-group baseline (Iyer: ¶28). Iyer further discloses counting failed authentication attempts for a specific user (Iyer: ¶32), and characterizing user activity according to quantity, time, duration, and duration between activities using login, network-access, document-access, and physical-access events (Iyer: ¶79). Iyer also discloses timestamped login events and identifying suspicious logins separated by an insufficient duration of time (Iyer: ¶¶98–101), as well as timestamped physical-access events associated with security checkpoints or restricted areas (Iyer: ¶¶105–107). Thus, Iyer teaches characterizing user behavior using quantities of access/authentication events, temporal relationships between access activities, and comparison with an organizational peer group.
It would therefore have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Kim as modified by Sprague, Banes, and Badana according to Iyer so that the user behavior information used in determining security risk includes the number of access attempts by the particular user, counts of authentication/access outcomes, the time difference between user requests or access activities, and correlation of the user's behavior with the user's organizational role or peer group. Iyer teaches that quantities of authentication events, temporal relationships between activities, physical and logical access events, and comparison against organizational peer-group behavior are useful indicators for identifying anomalous activity and updating a user's security risk score. The motivation to combine would have been to improve the accuracy of the risk determination by characterizing the user's current access behavior against both the user's historical activity and the expected activity associated with similarly situated users.
Regarding Claim 10
Kim as modified by Sprague, Banes, Badana, and Iyer discloses the limitations of claim 7. However, Kim, Sprague, Banes, and Badana do not expressly disclose wherein the user-role information indicates an organizational role of the user. Iyer further discloses user information identifying a user's organizational role or privilege level and using that information in determining security risk. Iyer discloses that a risk score modifier may depend upon whether the user performing an activity is a system administrator, explaining that activity performed by a system administrator may warrant a reduced risk score while the same activity performed by a non-privileged user may appear associated with an elevated risk score (Iyer: ¶47). Iyer further discloses grouping employees according to organizational units or peer groups, including Human Resources, Finance, and Marketing, and establishing baseline behavior for those organizational peer groups so that an employee's behavior may be compared with the expected behavior of the peer group (Iyer: ¶28). Iyer additionally explains that monitored entities may be employees, contractors, consultants, or other entities having access to organizational information and that statistical baselines may be established for an organization or an organizational unit such as a department or group (Iyer: ¶77).
It would therefore have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify Kim as modified by Sprague, Banes, and Badana according to Iyer so that the user role information used in the security risk determination indicates the organizational role of the user. Iyer teaches distinguishing users according to organizational privilege and organizational grouping, including distinctions between system administrators and non-privileged users and between employees belonging to different organizational units. The motivation to combine would have been to improve the accuracy of the security-risk determination by evaluating a user's activity in view of the permissions and expected behavior associated with that user's organizational role.
Regarding Claim 13
Claim 13 is directed to a system corresponding to the computer-implemented method in claim 8. Claim 13 is similar in scope to claim 8 and is therefore rejected under similar rationale.
Regarding Claim 15
Claim 15 is directed to a system corresponding to the computer-implemented method in claim 10. Claim 15 is similar in scope to claim 10 and is therefore rejected under similar rationale.
Claims 16-17 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim in view of Sprague and Banes as applied to claim 11 and 19 above, and in further view of Richards (US 2015/0156098 A1).
Regarding Claim 16
Kim as modified by Sprague, Banes, and Badana discloses the limitations of the parent claim. However, the combination does not expressly disclose wherein the server is configured to generate an alert in response to causing the user device to deny the request to use the one or more system resources. Richards further discloses detecting a prescribed condition in network traffic and, upon detection of the condition, generating an alert and executing an associated action. Richards discloses that, when a trigger is detected, “an alert is executed” and, in parallel, any recorded action associated with the trigger is also executed (Richards: ¶68). Richards further discloses that such actions may include truncating or redirecting network traffic (Richards: ¶46) and that, in network-security applications, automated alerts and prescribed or dynamically determined actions may isolate, trap, or reject the passage of detected threats (Richards: ¶87).
It would therefore have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Kim as modified by Sprague, Banes, and Badana according to Richards so that, when an access request is denied in response to detecting an unacceptable security condition, the server also generates an alert associated with the denied request. Richards teaches generating alerts together with responsive interdiction or rejection actions upon detection of an undesirable network condition. The motivation to combine would have been to provide an administrator or monitoring system with immediate notice that a request was denied because of a detected security condition, thereby facilitating timely investigation and response.
Regarding Claim 17
Kim as modified by Sprague, Banes, Badana, and Richards discloses the limitations of claim 16. Richards further discloses providing an alert to another system or device using email and/or short message service (SMS). Richards discloses that the rules engine generates responses including email alerts (Richards: ¶49). Richards further discloses that visualization and notification of live-data alerts may provide live output to other systems using email, SMS, etc. (Richards: ¶58).
It would therefore have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to configure the alert of claim 16 to be provided to another device using email or SMS, as taught by Richards. The motivation to combine would have been to provide the security alert through conventional remote notification mechanisms so that an administrator or other responsible user may receive timely notice of the denied or blocked activity.
Regarding Claim 20
Claim 20 is directed to a system corresponding to the computer-implemented method in claim 16. Claim 20 is similar in scope to claim 16 and is therefore rejected under similar rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD ABDULLAH whose telephone number is 571 -272-1531. The examiner can normally be reached on Monday-Friday 9am-5pm EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, LYNN FIELD can be reached on 571-272-2092.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SAAD AHMAD ABDULLAH/ Examiner, Art Unit 2431
/LYNN D FEILD/ Supervisory Patent Examiner, Art Unit 2431
