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 .
DETAILED ACTION
The instant application having Application No. 18/429,078 is presented for examination by the examiner. Claim 3 is canceled. Claims 1, 6, 11, 16 and 18-20 are amended. Claim 21 is newly added, Claims 1-2 and 4-21 have been examined.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 11 and 18 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 current amendments overcome the previous 35 USC §112(b) rejection.
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).
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 and 210: teaches receiving, at a user device, a key request for a cryptographic key assigned to the user device, where the SKI authenticatee detects user input to initiate a request to register a device for authentication, and in response displays a GUI to facilitate device or user authentication associated with the device’s cryptographic credentials.);
providing the cryptographic key to the user device for use in confirming an identity of the user device or a user of the user device to a user risk analyzer executing on a computing platform (Kim ¶148, 149, 220: teaches providing the cryptographic key to the user device for use in confirming an identity of the user device or a user of the user device, where, after verification of authentication information, the external device generates and encrypts an authentication key mapped to the user device and account, transmits the symmetric key to the user device, and subsequently uses the key during authentication operations to verify identity and permit access to computing resources.);
receiving, from the user device, data encrypted according to the cryptographic key assigned to [[a]] the user device requesting to use one or more system resources (Kim ¶250: teaches receiving, from the user device, data encrypted according to a cryptographic key assigned to the user device, where the first electronic device encrypts and signs authentication information using its private key and transmits the encrypted authentication information to the second electronic device in response to an authentication request, the encrypted data being used to authenticate the device and enable access to system resources.);
verifying an authenticity of the cryptographic key for the user device corresponding to confirming [[an]] the identity of the user device or [[a]] the user (Kim ¶148, 251, 280: teach verifying an authenticity of the cryptographic key for the user device corresponding to confirming the identity of the user device or the user, where the external device verifies a signature of authentication information using a public key corresponding to the user device’s private key, and confirms device and user identity by determining whether the decrypted authentication information is valid based on the cryptographic verification.);
Kim teaches a system in which a user device is assigned a unique cryptographic identifier and uses it to securely authenticate with a remote system via dynamic tamper-resistant credentials. However, they do not disclose the following limitation “determining a level of security risk posed by the request from the user device to an organization in response to verifying the cryptographic key is authentic; outputting a risk score indicative of the level of security risk posed by the request to the organization; determining whether the risk score is less than or equal to a risk score threshold; one of: granting the user device access to use the one or more system resources in response to the determining that the risk score is less than or equal to the risk score threshold; and denying the user device the request to use one or more system resources in response to determining that the risk score is greater than the risk score threshold”
However, in an analogous art, Sprague discloses a risk score system/method that includes:
determining a level of security risk posed by the request from the user device to an organization in response to verifying the cryptographic key is authentic (Sprague ¶43–44, 81, 86–89, and 134–136: The system verifies device identity using various unique identifiers, including cryptographic keys. These keys are authenticated, and the trustworthiness of the device is assessed using those keys as part of a broader trust score calculation.);
outputting a risk score indicative of the level of security risk posed by the request to the organization (Sprague ¶43-44, 126, 136: teaches a system that computes a trust score based on factors such as cryptographic key verification, device identity, and contextual verification. This trust score is a numerical value that indicates the system’s confidence in the authenticity and security of the requesting device. The trust score is then output to the third-party service provider (organization), which uses it to determine whether access should be granted.);
determining whether the risk score is less than or equal to a risk score threshold;
one of:
granting the user device access to use the one or more system resources in response to the determining that the risk score is less than or equal to the risk score threshold; and
denying the user device the request to use one or more system resources in response to determining that the risk score is greater than the risk score threshold (Sprague ¶43–44, 126: The system receives a request from a user device to access one or more system resources. It evaluates the request by computing a trust score based on factors such as cryptographic key verification and contextual device information. The system then determines whether the computed trust score meets a trust score threshold defined by the third-party service provider. Sprague ¶44 and 89: further teaches that if the trust score is insufficient (fails to meet the threshold) the system either terminates the session or withholds access, thereby effectively denying access to the requested resources. Sprague ¶138: further teaches if the trust score meets or exceeds the threshold, the system permits the device to access system resources, with different levels of access granted depending on the trust score. This effectively authorizes and grants access to the requested resource.).
Given the teachings of Sprague, a person having ordinary skill in the art before the effective filing date of the claimed invention would have recognized the desirability of modifying the teaching of Kim by determining a level of security risk based on cryptographic key verification, outputting a risk score, and comparing that score to a threshold to govern access to system resources. Sprague discloses verifying cryptographic keys to assess device authenticity, and generating a trust score that reflects the security risk posed by the user device. This trust score is then evaluated against a threshold to determine whether the request should be granted or denied. Sprague also teaches denying access when the score falls below the threshold and granting full or partial access when it meets or exceeds the threshold. It would have been obvious to implement this approach to manage user access requests, as it ensures that only devices with sufficiently verified identities and low risk are granted access, improving organizational security (Sprague ¶43–44, 126 and 138).
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 and 220: teaches assigning a cryptographic key to a user device, where, after successful authentication, the external device generates an authentication key (e.g., a symmetric key), encrypts and stores the key in a secure area, and maps and registers the cryptographic key to the specific electronic device as a companion device for subsequent authenticated use).
Regarding Claim 18
A system comprising: one or more computing platforms configured to:
receive a key request for a cryptographic key assigned to a user device; generate a guided user interface (GUI), the GUI allowing a user of the user device to provide the cryptographic key to the user device for use in confirming an identity of the user device or the user to a user risk analyzer executing on a computing platform (Kim ¶184-185, 192, 258: teaches encrypting and using cryptographic authentication keys in user-device communications, where a cryptographic key is generated and securely stored following successful authentication, a guided user interface is generated at the user device to authenticate the user and provision the cryptographic key, and encrypted authentication data is subsequently received and processed to permit access to protected system resources such as logon or approval operations on a computing platform.).
receive data encrypted according to [[a]] the cryptographic key assigned to [[a]] the user device requesting to use one or more system resources (Kim ¶250: teaches receiving, from the user device, data encrypted according to a cryptographic key assigned to the user device, where the first electronic device encrypts and signs authentication information using its private key and transmits the encrypted authentication information to the second electronic device in response to an authentication request, the encrypted data being used to authenticate the device and enable access to system resources.);
verify an authenticity of the cryptographic key for the user device corresponding to confirming [[an]] the identity of the user device or [[a]] the user of the user device (Kim ¶148, 251, 280: teach verifying an authenticity of the cryptographic key for the user device corresponding to confirming the identity of the user device or the user, where the external device verifies a signature of authentication information using a public key corresponding to the user device’s private key, and confirms device and user identity by determining whether the decrypted authentication information is valid based on the cryptographic verification.);
Kim teaches a system in which a user device is assigned a unique cryptographic identifier and uses it to securely authenticate with a remote system via dynamic tamper-resistant credentials. However, they do not disclose the following limitation “determine a level of security risk posed by the request from the user device to an organization in response to verifying the cryptographic key is authentic; output a risk score indicative of the level of security risk posed by the request to the organization; determine whether the risk score is less than or equal to a risk score threshold; one of: grant the user device access to use the one or more system resources in response to the determining that the risk score is less than or equal to the risk score threshold; and deny the user device the request to use the one or more system resources in response to determining that the risk score is greater than the risk score threshold.”
However, in an analogous art, Sprague discloses a risk score system/method that includes:
determine a level of security risk posed by the request from the user device to an organization in response to verifying the cryptographic key is authentic (Sprague ¶43–44, 81, 86–89, and 134–136: The system verifies device identity using various unique identifiers, including cryptographic keys. These keys are authenticated, and the trustworthiness of the device is assessed using those keys as part of a broader trust score calculation.);
output a risk score indicative of the level of security risk posed by the request to the organization (Sprague ¶43-44, 126, 136: teaches a system that computes a trust score based on factors such as cryptographic key verification, device identity, and contextual verification. This trust score is a numerical value that indicates the system’s confidence in the authenticity and security of the requesting device. The trust score is then output to the third-party service provider (organization), which uses it to determine whether access should be granted.); ;
determine whether the risk score is less than or equal to a risk score threshold; one of: grant the user device access to use the one or more system resources in response to the determining that the risk score is less than or equal to the risk score threshold; and deny the user device the request to use the one or more system resources in response to determining that the risk score is greater than the risk score threshold (Sprague ¶43–44, 126: The system receives a request from a user device to access one or more system resources. It evaluates the request by computing a trust score based on factors such as cryptographic key verification and contextual device information. The system then determines whether the computed trust score meets a trust score threshold defined by the third-party service provider. Sprague ¶44 and 89: further teaches that if the trust score is insufficient (fails to meet the threshold) the system either terminates the session or withholds access, thereby effectively denying access to the requested resources. Sprague ¶138: further teaches if the trust score meets or exceeds the threshold, the system permits the device to access system resources, with different levels of access granted depending on the trust score. This effectively authorizes and grants access to the requested resource.).
Given the teachings of Sprague, a person having ordinary skill in the art before the effective filing date of the claimed invention would have recognized the desirability of modifying the teaching of Kim by determining a level of security risk based on cryptographic key verification, outputting a risk score, and comparing that score to a threshold to govern access to system resources. Sprague discloses verifying cryptographic keys to assess device authenticity, and generating a trust score that reflects the security risk posed by the user device. This trust score is then evaluated against a threshold to determine whether the request should be granted or denied. Sprague also teaches denying access when the score falls below the threshold and granting full or partial access when it meets or exceeds the threshold. It would have been obvious to implement this approach to manage user access requests, as it ensures that only devices with sufficiently verified identities and low risk are granted access, improving organizational security (Sprague ¶43–44, 126 and 138).
Regarding Claim 21
The method of claim 1, further comprising generating a guided user
interface (GUI) at the user device, the GUI configured to provide the cryptographic
key to the user device (Kim ¶184-185, 192, 258: teaches encrypting and using cryptographic authentication keys in user-device communications, where a cryptographic key is generated and securely stored following successful authentication, a guided user interface is generated at the user device to authenticate the user and provision the cryptographic key, and encrypted authentication data is subsequently received and processed to permit access to protected system resources such as logon or approval operations on a computing platform.).
Claims 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim (US 20180109947 A1), in view of Sprague (US 20220021664 A1) as applied to claim 1 above, and in further view of Venkatesan (US 2024/0121081 A1).
Regarding Claim 4
Kim and Sprague teach a system that generates and verifies cryptographic key tied to device-specific parameters and risk scores to confirm user/device identity and determine access authorization based on a security risk threshold. However, they do not disclose the following limitation “wherein the cryptographic key is verified as authentic in response to a successful description of the encrypted data.”
However, in an analogous art, Venkatesan discloses a cryptographic key system/method that includes:
The computer-implemented method of claim 1, wherein the cryptographic key is verified as authentic in response to a successful description of the encrypted data (Venkatesan ¶109-110 and 118-119: The system generates a decryption key using a shared secret associated with the attribute and uses it to decrypt cyphertext received from the user device. If the decryption is successful, the system proceeds to authenticate the user and allow access to the resource.).
Given the teachings of Venkatesan, a person having ordinary skill in the art would have found it obvious to modify the teachings of Kim and Sprague to verify a cryptographic key’s authenticity based on successfully decryption of encrypted data. Venkatesan describes generating a decryption key from shared secret and using it to decrypt ciphertext from a user deice. If the decryption succussed, the system authenticates the user and grants access, effectively confirming the key’s authenticity (Venkatesan ¶109-110 and 118-119).
Claims 5-15, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim (US 20180109947 A1), in view of Sprague (US 20220021664 A1) as applied to claim 1 above, and in further view of Badana (US 11,743,298 B2).
Regarding Claim 5
Kim and Sprague teach a system that generates and verifies cryptographic key tied to device-specific parameters and risk scores to confirm user/device identity and determine access authorization based on a security risk threshold. However, they do not disclose the following limitation “wherein the level of security of risk is determined based on a user role information for the user, user behavior information for the user, and system log information”
However, in an analogous art, Badana discloses a risk threshold system/method that includes:
The computer-implemented method of claim 1, wherein the level of security of risk is determined based on a user role information for the user (Badana Column 5, Lines 19-39; Column 11, Lines 15-29: teaches that risk levels are determined based on user profiles, which reflects user roles and influences ML-generated priority level and policy enforcements.), user behavior information for the user (Badana Column 20, Lines 7-17 and Column 21, Lines 18-22: teaches that user behavior is continuously monitored and analysed through browsing history and activity patterns, which are classified over time and used by the system to determine risk.) and system log information (Badana Column 8, Line 65 – Column 9, Line 6; Column 10, Lines 30-47: teaches collecting and analyzing system log information such as DNS/URL request and browsing history logs, these are used to evaluate access attempts and determine associated risk.).
Given the teachings of Badana, a person having ordinary skill in the art would have found it obvious to modify the teachings of Kim and Sprague to determine a level of security risk based on user role information, user behavior information, and system log information. Badana (Column 5, Lines 19-39; Column 11, Lines 15-29) teaches that user profiles, which include user roles, are used to influence policy enforcement and prioritize security response. Badana (Column 20, Lines 7-17 and Column 21, Lines 18-22) also teaches continuously analyzing user behavior such as browsing history and activity patterns to classify risk levels over time. Badana (Column 8, Line 65 – Column 9, Line 6; Column 10, Lines 30-47) teaches analyzing system log data, including URL and DNS requests to assess access attempts and evaluate associated risks. Taken together these disclosures render it obvious to combine user roles, behavioral patterns, and log data to assess the user’s risk level in a security system.
Regarding Claim 6
Kim and Sprague teach a system that generates and verifies cryptographic key tied to device-specific parameters and risk scores to confirm user/device identity and determine access authorization based on a security risk threshold. However, they do not disclose the following limitation “wherein a machine learning (ML) model is used to determine the level of security risk posed by the request from the user device to the organization and outputting [[a]] the risk score indicative of the level of security risk posed by the request to the organization”
However, in an analogous art, Badana discloses a risk threshold system/method that includes:
The computer-implemented method of claim 1, wherein a machine learning (ML) model is used to determine the level of security risk posed by the request from the user device to the organization and outputting [[a]] the risk score indicative of the level of security risk posed by the request to the organization (Badana Column 2, Lines 28-37: teaches using machine learning models to analyze user activity and determine a risk score, which is then used to decide whether to authorize a data access request from a user device).
Given the teachings of Badana, a person having ordinary skill in the art would have found it obvious to modify the teachings of Kim and Sprague to use a ML model to determine a level of security risk posed by a request from a user device and to output a corresponding risk score. Badana (Column 2, Lines 28-37) teaches applying ML models to analyze user activity and compute a risk score, which is used to assess a decision regarding data access request from user device. This aligns with using an ML model to assess the security risk of a request and generate a risk score indicative of that risk.
Regarding Claim 7
Kim and Sprague teaches a system that generates and verifies cryptographic key tied to device-specific parameters and risk scores to confirm user/device identity and determine access authorization based on a security risk threshold. However, they do not disclose the following limitation “wherein the ML model is configured to determine the level of security risk posed by the request from the user device to the organization based on a user role information for the user, user behavior information for the user, and system log information”
However, in an analogous art, Badana discloses a risk threshold system/method that includes:
The computer-implemented method of claim 6, wherein the ML model is configured to determine the level of security risk posed by the request from the user device to the organization based on a user role information for the user (Badana Column 5, Lines 22-29 and Column 11, Lines 23-29: teaches that the ML model generates risk-related priority levels using a user profile information, which reflects user roles and influences policy enforcement.), user behavior information for the user (Badana Column 20, Lines 7-34: teaches that the ML model analyzes user behavior over time including browsing patterns and activity frequency to assess risk.) and system log information (Badana Column 8, Line 65 – Column 9, Line 6; Column 10, Lines 30-47: teaches collecting and analyzing system log information such as DNS/URL request and browsing history logs, which are then used to evaluate access attempts and determine associated risks by an ML model.).
Given the teachings of Badana, a person having ordinary skill in the art would have found it obvious to modify the teachings of Kim and Sprague to configure a ML model to determine the level of security risk posed by a user device request based on user role information, user behavior, and system log data. Bandana (Column 5, Lines 22-29 and Column 11, Lines 23-29) teaches that user profiles (user roles) are used by the ML model to generate risk-based priority levels that inform policy enforcement. Badana (Column 20, Lines 7-34) further teaches analyzing user behavior patterns over time to assess risk. Additionally, Bandana (Column 8, Line 65 – Column 9, Line 6; Column 10, Lines 30-47) describe using system logs such as DNS and URL request as ML model inputs for evaluating access risk.
Regarding Claim 8
Kim and Sprague teaches a system that generates and verifies cryptographic key tied to device-specific parameters and risk scores to confirm user/device identity and determine access authorization based on a security risk threshold. However, they do not disclose the following limitation “wherein the user behavior information indicates how many access points has this specific user tried to enter, a number of successful and denied access requests, a time difference between requests, and a correlation with a user role of the user”
However, in an analogous art, Badana discloses a risk threshold system/method that includes:
The computer-implemented method of claim 6, wherein the user behavior information indicates how many access points has this specific user tried to enter (Badana Column 10, Lines 33-47: teaches that the system logs each third-party websites that the user has tried to visit, this inherently reflects how many access points the specific user attempted to enter.), a number of successful and denied access requests (Badana Column 11, Lines 40-55; Column 12, Lines 9-13: teaches that the system performs and logs authorization decisions for each user request either permitting or denying access which supports tracking the number of successful and denied access request as part of user behavior analysis.), a time difference between requests (Badana Column 6, Lines 2-13; Column 11, Lines 40-55: teaches the access request are restricted based on specific time window and daily limits and that each request is individually logged when made. A person skilled in the art would understand that enforcing these time-based policies requires tracking and comparing time stamps of access event which allows the system to calculate the time difference between requests.), and a correlation with a user role of the user (Badana Column 9, Line 64 – Column 10, Line 29: teaches that policies and authorized content are determined based on the user profile, which reflects a user’s role and these role-based profiles influence access decisions and risk evaluation.).
Given the teachings of Badana, a person having ordinary skill in the art would have found it obvious to modify the teachings of Kim and Sprague to use user behavior information including the number of access points attempted, the number of successful and denied request, the time difference between request, and a correlation with the user’s role to assess security risk. Badana (Column 10, Lines 33-47) teaches logging each third-party site a user visit which reflects the number of access points attempted. Badana (Column 11, Lines 40-55; Column 12, Lines 9-13) further discloses logging whether access request are granted or denied, enabling a count of successful and denied request. Badana (Column 6, Lines 2-13; Column 11, Lines 40-55) describes enforcing time-based access restrictions, which requires logging timestamps and enables calculating time differences between requests. Lastly, Badana (Column 9, Line 64 – Column 10, Line 29) links access policies to user roles allowing correlation of behavior with user roles. Therefore, it would be obvious to track and analyze these behavioral factor together to evaluate user activity and risk.
Regarding Claim 9
Kim and Sprague teach a system that generates and verifies cryptographic key tied to device-specific parameters and risk scores to confirm user/device identity and determine access authorization based on a security risk threshold. However, they do not disclose the following limitation “wherein the system log information characterizes a server name, server internet protocol (IP) address, files name, location, system owner, operating system (OS) type, source IP address, destination IP address, application name, application identifier (ID), running services, and/or time”
However, in an analogous art, Badana discloses a risk threshold system/method that includes:
The computer-implemented method of claim 6, wherein the system log information characterizes a server name, server internet protocol (IP) address, files name, location, system owner, operating system (OS) type, source IP address, destination IP address (Badana Column 11, Lines 40-55; Column 12, Lines 1-13: describes logging and analyzing user request to third-party content, flagging malicious links, and applying ML-based authorization rules. All of these actions inherently rely on identifying source and destination IP addresses.), application name, application identifier (ID), running services, and/or time.
Given the teachings of Badana, a person having ordinary skill in the art would have found it obvious to modify the teachings of Kim and Sprague to include source and destination IP addresses in system log information which are used for access analysis. Badana (Column 11, Lines 40-55; Column 12, Lines 1-13) teaches logging user request and applying ML-based authorization which requires identifying both the users source IP and destination IP address to evaluate and enforce security policies.
Regarding Claim 10
Kim and Sprague teach a system that generates and verifies cryptographic key tied to device-specific parameters and risk scores to confirm user/device identity and determine access authorization based on a security risk threshold. However, they do not disclose the following limitation “wherein the user role information indicates an organizational role of the user”
However, in an analogous art, Badana discloses a risk threshold system/method that includes:
The computer-implemented method of claim 6, wherein the user role information indicates an organizational role of the user (Badana Column 13, Lines 50-55 and Column 20, Lines 11-17: The system assigns policies to user profiles. These user profiles are used to manage access to third-party content and are tailored to different users within an organization thereby indicating an organizational role.).
Given the teachings of Badana, a person having ordinary skill in the art would have found it obvious to modify the teachings of Kim and Sprague to use role information indication an organization role of the user. Badana (Column 13, Lines 50-55 and Column 20, Lines 11-17) describes enterprise administrators assigning access policies to user profiles based on organization structure via an IT module. These profiles control content access and are tailored per user which reflects the user’s role within the organization.
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: device;
receive a key request for the cryptographic key assigned to the user generate a guided user interface (GUI), the GUI allowing a user to provide the cryptographic key to the user device for use in confirming an identity of the user device or the user of the user device to a user risk analyzer executing on a computing platform (Kim ¶ 184-185, 214, 225: teaches receiving a cryptographic key registration request and, in response, generating a guided user interface at the user device for device or user authentication, where user input provided through the GUI is used to confirm identity, after which a cryptographic authentication key is generated, encrypted, and provisioned for use by the user device.);
encrypt data according to the cryptographic key, the data comprising a request to use one or more system resources (Kim ¶248–251, 280–283: teaches encrypting data according to a cryptographic key, where the encrypted data comprises a request to use one or more system resources, as the electronic device encrypts and signs authentication information using a private or symmetric cryptographic key and transmits the encrypted authentication data to an external device, which verifies the encrypted data and, upon successful verification, grants access to system resources such as device login, application access, or other protected operations.);
Kim teach a system that generates and verifies cryptographic key tied to device-specific parameters and risk scores to confirm user/device identity and determine access authorization based on a security risk threshold. However, they do not disclose the following limitation “output, system resources in response to determining that the risk score is greater than the risk score threshold”
output, (Sprague ¶43-44, 126, 136: teaches a system that computes a trust score based on factors such as cryptographic key verification, device identity, and contextual verification This trust score is a numerical value that indicates the system’s confidence in the authenticity and security of the requesting device. The trust score is then output to the third-party service provider (organization), which uses it to determine whether access should be granted ).);
determining whether the risk score is less than or equal to a risk score threshold;
one of:
causing the user device to be granted access to use the one or more system resources in response to the determining that the risk score is less than or equal to the risk score threshold; and causing the user device to deny the request to use one or more system resources in response to determining that the risk score is greater than the risk score threshold (Sprague ¶43–44, 126: The system receives a request from a user device to access one or more system resources. It evaluates the request by computing a trust score based on factors such as cryptographic key verification and contextual device information. The system then determines whether the computed trust score meets a trust score threshold defined by the third-party service provider. Sprague ¶44 and 89 further teaches that if the trust score is insufficient (fails to meet the threshold) the system either terminates the session or withholds access, thereby effectively denying access to the requested resources. Sprague ¶138: further teaches if the trust score meets or exceeds the threshold, the system permits the device to access system resources, with different levels of access granted depending on the trust score. This effectively authorizes and grants access to the requested resource.).
Given the teachings of Sprague, a person having ordinary skill in the art before the effective filing date of the claimed invention would have recognized the desirability of modifying the teaching of Kim by determining a level of security risk based on cryptographic key verification, outputting a risk score, and comparing that score to a threshold to govern access to system resources. Sprague discloses verifying cryptographic keys to assess device authenticity, and generating a trust score that reflects the security risk posed by the user device. This trust score is then evaluated against a threshold to determine whether the request should be granted or denied. Sprague also teaches denying access when the score falls below the threshold and granting full or partial access when it meets or exceeds the threshold. It would have been obvious to implement this approach to manage user access requests, as it ensures that only devices with sufficiently verified identities and low risk are granted access, improving organizational security (Sprague ¶43–44, 126 and 138).
Kim and Sprague teach a system that generates and verifies cryptographic key tied to device-specific parameters and risk scores to confirm user/device identity and determine access authorization based on a security risk threshold. However, they do not disclose the following limitation “using a machine learning (ML) model … determining whether the risk score is less than or equal to a risk score threshold”
However, in an analogous art, Badana discloses a risk threshold system/method that includes:
using a machine learning (ML) model … determining whether the risk score is less than or equal to a risk score threshold (Badana Column 2, Lines 28-37: teaches using machine learning models to analyze user activity and determine a risk score and compare it to a threshold value, which is then used to decide whether to authorize a data access request from a user device).
Given the teachings of Badana, a person having ordinary skill in the art would have found it obvious to modify the teachings of Kim and Sprague to use a ML model to determine a level of security risk posted by a request from a user device and to output a corresponding risk score. Badana (Column 2, Lines 28-37) teaches applying ML models to analyze user activity and compute a risk score, which is used to access control decision regarding data request from user device. This aligns with using an ML model to assess the security risk of a request and generate a risk score indicative of that risk.
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 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 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 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.
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 16-17 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kim (US 20180109947 A1), in view of Sprague (US 20220021664 A1) in view of Badana (US 11,743,298 B2) as applied to claim 10 above, and in further view of Richards (US 2015/0156098 A1).
Regarding Claim 16
Kim, Sprague and Badana can be combined to teach a system that generates and verifies cryptographic key tied to device-specific parameters and risk scores to confirm user/device identity and determine access authorization based on a security risk threshold. However, they do not disclose the following limitation “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”
However, in an analogous art, Richards discloses an alert system/method that includes:
The system of claim 10, 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 ¶46, 49 and 58: teaches that the system (via ingestor and semantic nodes) can detect certain conditions in live traffic and deny access to resource. The system then generates an alert though email or SMS notification in response to the denial.).
Given the teachings of Badana, a person having ordinary skill in the art would have found it obvious to modify the teachings of Kim, Sprague and Badana to configure a server to generate an alert in response to causing a user device to deny a request to access system resources. Richards (¶46, 49 and 58) discloses a system that monitors live traffic and upon detecting suspicious activity denies access while generating an alert though email or SMS to inform administrator of the blocked actions. Implementing such action would be obvious to a person in the art as it provides immediate awareness of suspicious data to the system administrators and facilitates a timely response.
Regarding Claim 17
Kim, Sprague and Badana can be combined to teach a system that generates and verifies cryptographic key tied to device-specific parameters and risk scores to confirm user/device identity and determine access authorization based on a security risk threshold. However, they do not disclose the following limitation “wherein the alert is provided to another device using one of an email and a short message service (SMS) message”
However, in an analogous art, Richards discloses an alert system/method that includes:
The system of claim 16, wherein the alert is provided to another device using one of an email and a short message service (SMS) message (Richards ¶46, 49 and 58: teaches that the system (via ingestor and semantic nodes) can detect certain conditions in live traffic and deny access to resource. The system then generates an alert though email or SMS notification in response to the denial.).
Given the teachings of Badana, a person having ordinary skill in the art would have found it obvious to modify the teachings of Kim, Sprague and Badana to configure a server to generate an alert in response to causing a user device to deny a request to access system resources. Richards (¶46, 49 and 58) discloses a system that monitors live traffic and upon detecting suspicious activity denies access while generating an alert though email or SMS to inform administrator of the blocked actions. Implementing such action would be obvious to a person in the art as it provides immediate awareness of suspicious data to the system administrators and facilitates a timely response.
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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD A ABDULLAH whose telephone number is (571) 272-1531. The examiner can normally be reached on Monday - Friday, 8:30am - 5:00pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571) 272-2092. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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
Prosecution Insights