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/02/2026 has been entered.
Response to Arguments
Applicant’s arguments filed 04/02/2026, with respect to the rejections of independent claims 1, 2, and 13 and their corresponding dependent claims under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, new grounds of rejection are made in view of the previously applied references from Balazs and Tischart, in addition to a newly applied reference from Ongpin et al. (US 20210224799 A1), hereinafter Ongpin. Ongpin teaches the amended limitations “processing … the resource access request by transmitting a request for a resource access history, corresponding to the user, that is based on a plurality of access records that include a first access record regarding usage of the secured authentication token by the user and a second access record regarding usage of the unsecured authentication token by the user”.
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.
Claim(s) 1-4, 6, 13-15, and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Balazs et al. (US 9444824 B1), hereinafter Balazs, in view of Tischart et al. (US 20180183789 A1), hereinafter Tischart, and Ongpin et al. (US 20210224799 A1), hereinafter Ongpin.
Regarding Claim 1:
Balazs teaches a system for managing resource access permissions for users with secured and unsecured authentication tokens (Balazs – Col. 7, Line 17-25: This process or module 114 may be used to identify a client, an entity, or a user (hereinafter a user) who attempts to access the system to access various products, services, resources, or actions or to perform certain actions; the process or module 114 may be further used to authenticate the user and then authorize the user to access certain permitted products, services, resources, or actions or to perform certain permitted actions in these embodiments; and Figure 8B: illustration of a plurality of tokens corresponding to varying levels of resource access), comprising: one or more processors; and one or more non-transitory computer-readable media storing instructions that when executed by the one or more processors cause operations (Balazs – Col. 21, Line 35-41: According to one embodiment of the invention, computer system 900 performs specific operations by one or more processors or processor cores 907 executing one or more sequences of one or more instructions contained in system memory 908. Such instructions may be read into system memory 908 from another computer readable/usable storage medium, such as static storage device 909 or disk drive 910) comprising: receiving, from a user, a resource access request for a system (Balazs – Col. 9, Line 20-25: the method or system may, at 302A, receive a user's request for access to a financial management system which may include, for example, a tax preparation product or service, an accounting product or service, a payroll product or service, or a personal or corporate finance product or service), wherein the resource access request comprises a user identifier and a first activity for the resource access request (Balazs – Col. 9, Line 27-40: The method or system may invoke a cyber-intelligence module at 304A and to identify one or more characteristics associated with the user's request at 306A to safeguard cybersecurity, computer security, or Internet fraud detection and prevention. In these embodiments, the one or more characteristics may include … the device identifications (e.g., media access control or MAC addresses) of the devices with which the user has used in issuing the requests; and Col. 20, Line 45-52: the method or system may further identify a change in the level of assurance upon receiving the user's request (e.g., by clicking or other types of user actions) to change the direct deposit account information or to access information including the user's taxpayer identification number (e.g., employer identification number, social security number, individual taxpayer identification number, etc.); Examiner’s Comment: this example demonstrates a resource access request which includes an activity for the request); retrieving information regarding authentication tokens associated with the user usable to process the resource access request (Balazs – Col. 20, Line 25-30: One or more characteristics associated with the user's request may be identified at 806D. The method or system may identify a first authentication token based at least in part upon the user's request or the identified one or more characteristics associated with the user's request at 808D by using at least the cyber-intelligence process or module); determining that the user is associated with a secured authentication token and an unsecured authentication token, wherein the unsecured authentication token is associated with higher priority resources compared to the secured authentication token (Balazs – Col. 20, Line 45-59: At 812D, the method or system may further identify a change in the level of assurance upon receiving the user's request (e.g., by clicking or other types of user actions) to change the direct deposit account information or to access information including the user's taxpayer identification number (e.g., employer identification number, social security number, individual taxpayer identification number, etc.). Assuming that the method or system determines that the user has not been authenticated to access such sensitive information, the method or system may further identify a second authentication token based at least in part upon the user's request to change direct deposit account information or to access the user's taxpayer identification number at 814D; and Col. 14, Line 35-46: Once the user is properly authenticated at an appropriate level of assurance associated with the adequate authentication scheme, the method or system may authorize the user to traverse the flow established in response to the user's request as far as the appropriate level of assurance permits at 512. For example, the user may be permitted to access the information or data or perform actions that are permitted by the appropriate level of assurance as well as lower levels of assurance associated with less sensitive, less confidential, or less critical information or data but is not permitted to access the information or data or perform actions that are permitted by higher levels of assurance; and Figure 8B: illustration of a plurality of tokens corresponding to varying levels of resource access; and Figure 7: illustration of levels of assurance granted by tiered tokens; Examiner’s Comment: The particular teaching in Column 14 of Balazs illustrates that a high-assurance token offers a user less-restricted or unrestricted access to system resources, corresponding to the description in the instant specification paragraph [0003], in which an unsecured system is described as: “with unsecured computer systems, known or vetted users may freely access and interact with the system without access control measures for different types of system resources. This setup can be more convenient and user-friendly, but it carries a higher risk of unauthorized access or potential misuse by unknown or lesser-known users” ), and wherein the unsecured authentication token requires a measure of risk [to be below a threshold risk] to avoid abuse of the higher priority resources (Balazs – Col. 10, Line 9-21: Once the user is properly authenticated, the method or the system may initiate a flow to fulfill the user's request for access to the financial management system at 312A. At 314A, the progression or traversal of the flow may be randomly, periodically, or continuously monitored by, for example, the level of assurance monitoring or enforcement module 112 to adaptively provide the adequate level of assurance based at least in part upon the sensitivity or criticality of the information to be presented to the user or action to be executed by the user. The method or system may the enhance the user experience while providing adequate security by using appropriate levels of assurance based at least in part upon the traversal of the flow at 316A; and Col. 11, Line 41-45: Based at least in part upon the user's request, the one or more characteristics associated with the user's request, the results of risk assessment or management, or the results of analyzing analytics, the method or system may determine an appropriate authentication scheme at 312B); in response to determining that the user is associated with the secured authentication token and the unsecured authentication token, processing, using a machine learning model, and to determine the measure of risk for executing the resource access request, the resource access request … resource access history (Balazs – Figure 3B: detailed flow of implementing adaptive levels of assurance to fulfill a user request; and Col. 9, Line 27-47: The method or system may invoke a cyber-intelligence module at 304A and to identify one or more characteristics associated with the user's request at 306A to safeguard cybersecurity, computer security, or Internet fraud detection and prevention. In these embodiments, the one or more characteristics may include, for example but not limited to, frequency of requests from the user such as the total number of requests from the user within a period of time, geographic locations in which the user has initiated the requests, network locations from which the user has initiated the requests, the device identifications (e.g., media access control or MAC addresses) of the devices with which the user has used in issuing the requests, actions of the user (e.g., merely browsing, copying, or printing information about personal information without actively attempting to further complete the flow), any other recognized or predicted behavior anomalies, or any combinations thereof. These one or more characteristics may be stored in one or more risk profiles or one or more policies referenced by various processes, modules, or systems described herein; and Col. 11, Line 24-40: Optional risk assessment or management may also be performed to assess, rank, or manage potential risks or threats or to associate the potential risks or threats with various levels of assurance or security measures at 308B by using, for example the risk assessment or management process or module 118 … At 310B, the method or system may optionally gather and analyze various analytics using the cyber-intelligence module to use various techniques including statistics, modeling, machine learning, or data mining to collect and analyze various types of current or historical data, information, or patterns to … identify or predict risks (e.g., the occurrence or likelihood of some future events); and Col. 12, Line 54-58: Based at least in part upon the identified potential threats or potential vulnerabilities, the method or system may identify or determine risks or levels of risks at 412 and map the identified or determined risks or levels of risks to appropriate levels of assurance at 414); and in response to determining that the measure of risk [is below the threshold risk], processing the resource access request for the first activity using the unsecured authentication token (Balazs – Col. 11, Line 41-56: Based at least in part upon the user's request, the one or more characteristics associated with the user's request, the results of risk assessment or management, or the results of analyzing analytics, the method or system may determine an appropriate authentication scheme at 312B. Upon the user's successful completion of the authentication and/or authorization processes, the method or system may then authorize the user to access at least a part of the financial management system that is associated with the current level of assurance as permitted or safeguarded by the identified authentication scheme at 314B. A flow may be initiated in response to the user's request at 316B, and the system or module may further monitor the traversal or progression of the flow for the user's session at 318B to ensure to provide adaptive levels of assurance as the user proceeds with the flow in the user's access to the financial management system).
Balazs does not expressly teach and wherein the unsecured authentication token requires a measure of risk to be below a threshold risk; and determining that the measure of risk is below the threshold risk.
However, Tischart teaches and wherein the unsecured authentication token requires a measure of risk to be below a threshold risk (Tischart – Paragraph [0036]: In at least one embodiment, operation 253 also includes providing the information stored in the security access database 210 to a context-aware decision logic/module 212, which may be part of the authentication entity 206 (as shown in FIG. 2). When a user of device 202A attempts to access a computer network (e.g., the network 100 of FIG. 1, etc.), the context-aware decision logic/module 212 uses the information associated with the current authentication session (i.e., the current identity data and the current contextual data being used for the current authentication session) and the data stored in the security access database 210 to determine a risk level associated with the current authentication session. If the risk level fails to exceed a threshold, the decision logic/module 212 does not trigger additional authentication sessions for the user of device 202. That is, the decision logic/module 212 will “inform” the authentication entity 206 to grant the user of device 202 access to the secure network based on the current authentication session (assuming the identity data used by the user of device 202 is in fact the correct information for successful authentication). Alternatively, if the risk level exceeds the threshold, the decision logic/module 212 triggers additional authentication sessions for the user of device 202A. Here, the decision logic/module 212 will cause the authentication entity 206 to request additional identity data from the user to establish confidence that the user is in fact who he/she claims to be; and Paragraph [0004]: identity data can be broken up into three authentication factors … (ii) an ownership factor, which is a physical or virtual object possessed by the user (e.g., an identification card, a security token, a software token, a hardware token, a device with a hardware and/or software token, etc.)); and determining that the measure of risk is below the threshold risk (Tischart – Paragraph [0036]: In at least one embodiment, operation 253 also includes providing the information stored in the security access database 210 to a context-aware decision logic/module 212, which may be part of the authentication entity 206 (as shown in FIG. 2). When a user of device 202A attempts to access a computer network (e.g., the network 100 of FIG. 1, etc.), the context-aware decision logic/module 212 uses the information associated with the current authentication session (i.e., the current identity data and the current contextual data being used for the current authentication session) and the data stored in the security access database 210 to determine a risk level associated with the current authentication session. If the risk level fails to exceed a threshold, the decision logic/module 212 does not trigger additional authentication sessions for the user of device 202).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs, further incorporating Tischart to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Tischart’s teaching to evaluate a risk level against a threshold to determine whether a token is sufficient to grant a user secure access to system resources into Balazs’s system for managing resource access using tokens which grant varying levels of resource access. This combination enhances the system by providing a logical separator for different tiers of authentication (tokens) to allow corresponding different tiers of resource access securely and efficiently.
The combination of Balazs and Tischart does not expressly teach processing … the resource access request by transmitting a request for a resource access history, corresponding to the user, that is based on a plurality of access records that include a first access record regarding usage of the secured authentication token by the user and a second access record regarding usage of the unsecured authentication token by the user.
However, Ongpin teaches processing … the resource access request by transmitting a request for a resource access history, corresponding to the user, that is based on a plurality of access records that include a first access record regarding usage of the secured authentication token by the user and a second access record regarding usage of the unsecured authentication token by the user (Ongpin – Paragraph [0027]: Thus, a first customer may have a first set of available authentication tokens, a second customer may have a second set of available authentication tokens, a third customer may have a third set of available authentication tokens, and so on. The authentication tokens that are available for each customer may be based upon the type of accounts associated with the customer, devices associated with the customer, and so forth. Paragraph [0054]: The customer data manager 108 may be configured to obtain data 408 related to the customer 404; and Paragraph [0055]: The data related to the customer may include customer level data and/or transaction level data. This data may include data such as, but not limited to, a date of a last challenge, the type of last challenge, whether the last challenge was successful, the number of times each of the authentication tokens were presented to the customer in a specific time frame, how many challenges were successful or failed over a period of time, and so on; and Paragraph [0056]: According to some implementations, the information related to the set of authentication tokens 402 and/or the customer data 408 may be retained in a central repository 410. For example, the authentication tokens available for a customer may be maintained in the central repository 410, as well as the available authentication tokens for other customers. Further, the data 408 related to the customer 404 (as well as other customers) may be stored in the central repository 410. In some implementations, the central repository 410 may be configured to retain current and future authentication methods available for each customer, as well as data related to the number of times each method has been presented to the customer and the result of the challenge (e.g., pass, fail); and Figure 7: illustration of a method for dynamic token-based access management based on user and token information/history; and Paragraph [0092]: FIG. 7 illustrates an example, non-limiting method 700 for entry point management, according to an aspect. The various aspects discussed herein allow for appropriate authentication methods to be presented to customers based on transaction type as well as authentication risk token score. Further, the various aspects provide dynamic authentication presentment challenges using previous challenge history and information. This may make it more difficult for bad actors and fraudsters to obtain access to accounts as the authentication challenge will not be predictable under the dynamic presentment. The ability to turn off certain authentication tokens in case of a compromise, including customer level compromises, is also provided. Further, additional authentication challenges (e.g., PIN plus AA OTP code) may be introduced if certain risk or score levels satisfy a threshold level. If a customer's authentication token risk score shows that the customer is at a low risk of compromise, a reduced authentication may be applied to that customer. In addition, the disclosed aspects may be enabled for other user types (e.g., guest, delegates), which may streamline development and authentication challenges).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs and Tischart, further incorporating Ongpin to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Ongpin’s teaching to consider historical usage data for different access tokens associated with a user for providing dynamically secured resource access into Balazs and Tischart’s combined system for managing resource access using tokens which grant varying levels of resource access. This additional functionality enhances the security of the system by determining a level of risk associated with a user and a plurality of tokens in real time, and requiring use of a token deemed appropriate for secure access based on recorded user-token activity.
Regarding Claim 2:
Balazs teaches a method for managing resource access permissions for users with secured and unsecured authentication tokens (Balazs – Col. 7, Line 17-25: This process or module 114 may be used to identify a client, an entity, or a user (hereinafter a user) who attempts to access the system to access various products, services, resources, or actions or to perform certain actions; the process or module 114 may be further used to authenticate the user and then authorize the user to access certain permitted products, services, resources, or actions or to perform certain permitted actions in these embodiments; and Figure 8B: illustration of a plurality of tokens corresponding to varying levels of resource access), comprising: receiving, from a user, a resource access request for a system (Balazs – Col. 9, Line 20-25: the method or system may, at 302A, receive a user's request for access to a financial management system which may include, for example, a tax preparation product or service, an accounting product or service, a payroll product or service, or a personal or corporate finance product or service), wherein the resource access request comprises a user identifier and a first activity for the resource access request (Balazs – Col. 9, Line 27-40: The method or system may invoke a cyber-intelligence module at 304A and to identify one or more characteristics associated with the user's request at 306A to safeguard cybersecurity, computer security, or Internet fraud detection and prevention. In these embodiments, the one or more characteristics may include … the device identifications (e.g., media access control or MAC addresses) of the devices with which the user has used in issuing the requests; and Col. 20, Line 45-52: the method or system may further identify a change in the level of assurance upon receiving the user's request (e.g., by clicking or other types of user actions) to change the direct deposit account information or to access information including the user's taxpayer identification number (e.g., employer identification number, social security number, individual taxpayer identification number, etc.); Examiner’s Comment: this example demonstrates a resource access request which includes an activity for the request); retrieving information regarding authentication tokens associated with the user usable to process the resource access request (Balazs – Col. 20, Line 25-30: One or more characteristics associated with the user's request may be identified at 806D. The method or system may identify a first authentication token based at least in part upon the user's request or the identified one or more characteristics associated with the user's request at 808D by using at least the cyber-intelligence process or module); the authentication tokens including a secured authentication token and an unsecured authentication token associated with the first user, wherein the unsecured authentication token is associated with higher priority resources compared to the secured authentication token (Balazs – Col. 20, Line 45-59: At 812D, the method or system may further identify a change in the level of assurance upon receiving the user's request (e.g., by clicking or other types of user actions) to change the direct deposit account information or to access information including the user's taxpayer identification number (e.g., employer identification number, social security number, individual taxpayer identification number, etc.). Assuming that the method or system determines that the user has not been authenticated to access such sensitive information, the method or system may further identify a second authentication token based at least in part upon the user's request to change direct deposit account information or to access the user's taxpayer identification number at 814D; and Col. 14, Line 35-46: Once the user is properly authenticated at an appropriate level of assurance associated with the adequate authentication scheme, the method or system may authorize the user to traverse the flow established in response to the user's request as far as the appropriate level of assurance permits at 512. For example, the user may be permitted to access the information or data or perform actions that are permitted by the appropriate level of assurance as well as lower levels of assurance associated with less sensitive, less confidential, or less critical information or data but is not permitted to access the information or data or perform actions that are permitted by higher levels of assurance; and Figure 8B: illustration of a plurality of tokens corresponding to varying levels of resource access; and Figure 7: illustration of levels of assurance granted by tiered tokens; Examiner’s Comment: The particular teaching in Column 14 of Balazs illustrates that a high-assurance token offers a user less-restricted or unrestricted access to system resources, corresponding to the description in the instant specification paragraph [0003], in which an unsecured system is described as: “with unsecured computer systems, known or vetted users may freely access and interact with the system without access control measures for different types of system resources. This setup can be more convenient and user-friendly, but it carries a higher risk of unauthorized access or potential misuse by unknown or lesser-known users”), wherein the unsecured authentication token is associated with higher priority resources compared to the secured authentication token (Balazs – Col. 10, Line 9-21: Once the user is properly authenticated, the method or the system may initiate a flow to fulfill the user's request for access to the financial management system at 312A. At 314A, the progression or traversal of the flow may be randomly, periodically, or continuously monitored by, for example, the level of assurance monitoring or enforcement module 112 to adaptively provide the adequate level of assurance based at least in part upon the sensitivity or criticality of the information to be presented to the user or action to be executed by the user. The method or system may the enhance the user experience while providing adequate security by using appropriate levels of assurance based at least in part upon the traversal of the flow at 316A; and Col. 11, Line 41-45: Based at least in part upon the user's request, the one or more characteristics associated with the user's request, the results of risk assessment or management, or the results of analyzing analytics, the method or system may determine an appropriate authentication scheme at 312B); processing, using a machine learning model, and to determine a measure of risk to the system that is associated with executing the resource access request for the first activity for the user, a resource access history (Balazs – Figure 3B: detailed flow of implementing adaptive levels of assurance to fulfill a user request; and Col. 9, Line 27-47: The method or system may invoke a cyber-intelligence module at 304A and to identify one or more characteristics associated with the user's request at 306A to safeguard cybersecurity, computer security, or Internet fraud detection and prevention. In these embodiments, the one or more characteristics may include, for example but not limited to, frequency of requests from the user such as the total number of requests from the user within a period of time, geographic locations in which the user has initiated the requests, network locations from which the user has initiated the requests, the device identifications (e.g., media access control or MAC addresses) of the devices with which the user has used in issuing the requests, actions of the user (e.g., merely browsing, copying, or printing information about personal information without actively attempting to further complete the flow), any other recognized or predicted behavior anomalies, or any combinations thereof. These one or more characteristics may be stored in one or more risk profiles or one or more policies referenced by various processes, modules, or systems described herein; and Col. 11, Line 24-40: Optional risk assessment or management may also be performed to assess, rank, or manage potential risks or threats or to associate the potential risks or threats with various levels of assurance or security measures at 308B by using, for example the risk assessment or management process or module 118. More details about risk assessment or management are described in the subsequent paragraphs with reference to FIG. 4. At 310B, the method or system may optionally gather and analyze various analytics using the cyber-intelligence module to use various techniques including statistics, modeling, machine learning, or data mining to collect and analyze various types of current or historical data, information, or patterns to, for example, analyze or identify opportunities (e.g., customer satisfaction level in using the financial management system) or to identify or predict risks (e.g., the occurrence or likelihood of some future events); and Col. 12, Line 54-58: Based at least in part upon the identified potential threats or potential vulnerabilities, the method or system may identify or determine risks or levels of risks at 412 and map the identified or determined risks or levels of risks to appropriate levels of assurance at 414); and in response to determining [that] the measure of risk [is below a threshold], processing the resource access request for the first activity using the unsecured authentication token (Balazs – Col. 11, Line 41-56: Based at least in part upon the user's request, the one or more characteristics associated with the user's request, the results of risk assessment or management, or the results of analyzing analytics, the method or system may determine an appropriate authentication scheme at 312B. Upon the user's successful completion of the authentication and/or authorization processes, the method or system may then authorize the user to access at least a part of the financial management system that is associated with the current level of assurance as permitted or safeguarded by the identified authentication scheme at 314B. A flow may be initiated in response to the user's request at 316B, and the system or module may further monitor the traversal or progression of the flow for the user's session at 318B to ensure to provide adaptive levels of assurance as the user proceeds with the flow in the user's access to the financial management system).
Balazs does not expressly teach determining that the measure of risk is below a threshold.
However, Tischart teaches determining that the measure of risk is below a threshold (Tischart – Paragraph [0036]: In at least one embodiment, operation 253 also includes providing the information stored in the security access database 210 to a context-aware decision logic/module 212, which may be part of the authentication entity 206 (as shown in FIG. 2). When a user of device 202A attempts to access a computer network (e.g., the network 100 of FIG. 1, etc.), the context-aware decision logic/module 212 uses the information associated with the current authentication session (i.e., the current identity data and the current contextual data being used for the current authentication session) and the data stored in the security access database 210 to determine a risk level associated with the current authentication session. If the risk level fails to exceed a threshold, the decision logic/module 212 does not trigger additional authentication sessions for the user of device 202).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs, further incorporating Tischart to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Tischart’s teaching to evaluate a risk level against a threshold to determine whether a token is sufficient to grant a user secure access to system resources into Balazs’s method for managing resource access using tokens which grant varying levels of resource access. This combination enhances the system by providing a logical separator for different tiers of authentication (tokens) to allow corresponding different tiers of resource access securely and efficiently.
The combination of Balazs and Tischart does not expressly teach a resource access history, corresponding to the first user, that includes a first access record regarding usage of the secured authentication token and a second access record regarding usage of the unsecured authentication token.
However, Ongpin teaches a resource access history, corresponding to the first user, that includes a first access record regarding usage of the secured authentication token and a second access record regarding usage of the unsecured authentication token (Ongpin – Paragraph [0027] Thus, a first customer may have a first set of available authentication tokens, a second customer may have a second set of available authentication tokens, a third customer may have a third set of available authentication tokens, and so on. The authentication tokens that are available for each customer may be based upon the type of accounts associated with the customer, devices associated with the customer, and so forth.
Paragraph [0054]: The customer data manager 108 may be configured to obtain data 408 related to the customer 404; and Paragraph [0055]: The data related to the customer may include customer level data and/or transaction level data. This data may include data such as, but not limited to, a date of a last challenge, the type of last challenge, whether the last challenge was successful, the number of times each of the authentication tokens were presented to the customer in a specific time frame, how many challenges were successful or failed over a period of time, and so on; and Paragraph [0056]: According to some implementations, the information related to the set of authentication tokens 402 and/or the customer data 408 may be retained in a central repository 410. For example, the authentication tokens available for a customer may be maintained in the central repository 410, as well as the available authentication tokens for other customers. Further, the data 408 related to the customer 404 (as well as other customers) may be stored in the central repository 410. In some implementations, the central repository 410 may be configured to retain current and future authentication methods available for each customer, as well as data related to the number of times each method has been presented to the customer and the result of the challenge (e.g., pass, fail); and Figure 7: illustration of a method for dynamic token-based access management based on user and token information/history; and Paragraph [0092]: FIG. 7 illustrates an example, non-limiting method 700 for entry point management, according to an aspect. The various aspects discussed herein allow for appropriate authentication methods to be presented to customers based on transaction type as well as authentication risk token score. Further, the various aspects provide dynamic authentication presentment challenges using previous challenge history and information. This may make it more difficult for bad actors and fraudsters to obtain access to accounts as the authentication challenge will not be predictable under the dynamic presentment. The ability to turn off certain authentication tokens in case of a compromise, including customer level compromises, is also provided. Further, additional authentication challenges (e.g., PIN plus AA OTP code) may be introduced if certain risk or score levels satisfy a threshold level. If a customer's authentication token risk score shows that the customer is at a low risk of compromise, a reduced authentication may be applied to that customer. In addition, the disclosed aspects may be enabled for other user types (e.g., guest, delegates), which may streamline development and authentication challenges).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs and Tischart, further incorporating Ongpin to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Ongpin’s teaching to consider historical usage data for different access tokens associated with a user for providing dynamically secured resource access into Balazs and Tischart’s combined system for managing resource access using tokens which grant varying levels of resource access. This additional functionality enhances the security of the system by determining a level of risk associated with a user and a plurality of tokens in real time, and requiring use of a token deemed appropriate for secure access based on recorded user-token activity.
Regarding Claim 3:
The combination of Balazs, Tischart, and Ongpin teaches the method of claim 2.
Balazs further teaches further comprising: receiving, from a second user (Balazs – Col. 5, Line 59-63: The software products or services provided to users may be installed on one or more of the plurality of remote computing devices 102, 104, or 106 or may be hosted in part or entirely on the computing system or cluster of computing systems 108), a second resource access request for the system (Balazs – Col. 9, Line 20-25: the method or system may, at 302A, receive a user's request for access to a financial management system which may include, for example, a tax preparation product or service, an accounting product or service, a payroll product or service, or a personal or corporate finance product or service), wherein the second resource access request comprises a second user identifier and a second activity for the second resource access request (Balazs – Col. 9, Line 27-40: The method or system may invoke a cyber-intelligence module at 304A and to identify one or more characteristics associated with the user's request at 306A to safeguard cybersecurity, computer security, or Internet fraud detection and prevention. In these embodiments, the one or more characteristics may include … the device identifications (e.g., media access control or MAC addresses) of the devices with which the user has used in issuing the requests; and Col. 20, Line 45-52: the method or system may further identify a change in the level of assurance upon receiving the user's request (e.g., by clicking or other types of user actions) to change the direct deposit account information or to access information including the user's taxpayer identification number (e.g., employer identification number, social security number, individual taxpayer identification number, etc.); Examiner’s Comment: this example demonstrates a resource access request which includes an activity for the request); retrieving information regarding authentication tokens associated with the second user usable to process the second resource access request (Balazs – Col. 20, Line 25-30: One or more characteristics associated with the user's request may be identified at 806D. The method or system may identify a first authentication token based at least in part upon the user's request or the identified one or more characteristics associated with the user's request at 808D by using at least the cyber-intelligence process or module); determining that the second user is only associated with a second secured authentication token, wherein a risk associated with activities executed with the second secured authentication token is accommodated by the second user (Balazs – Col. 1, Line 47-67 and Col. 2, Line 1-2: The method associate various flow nodes in a flow for using a software product or service including the financial management system with one or more levels of assurance. The one or more levels of assurance are further associated with or mapped to some authentication tokens having different authentication strengths. When a user first requests to access the software product or service, the user may be first authenticated with a lower authentication strength token or even no authentication required. The method may optionally examine the request for access or one or more characteristics associated with the request for access to determine whether or not a heightened level of assurance having a higher authentication strength token than the lower authentication strength token is required or desired to authenticate and authorize the user issuing the request for access for fraud detection or fraud prevention purposes. The user may then be authorized to access the data or information or to perform actions permitted by the authorized level of assurance corresponding to the lower authentication strength token or no authentication. The user is thus not burdened by the more complex authentication efforts required by higher authentication tokens of higher authentication strengths); and processing the second resource access request for the second activity using the second secured authentication token (Balazs – Col. 1, Line 64-67: The user may then be authorized to access the data or information or to perform actions permitted by the authorized level of assurance corresponding to the lower authentication strength token or no authentication).
The motivation to combine the arts is the same as that of Claim 2.
Regarding Claim 4:
The combination of Balazs, Tischart, and Ongpin teaches the method of claim 2.
Tischart further teaches comprising: receiving, from a database, the resource access history for the first user (Tischart – Paragraph [0036]: In at least one embodiment, operation 253 also includes providing the information stored in the security access database 210 to a context-aware decision logic/module 212; and Paragraph [0032]: the context-aware authentication logic/module 201 gathers at least some of the data associated with authenticating a user of the device 202 that is attempting to gain access to the computer network (e.g., network 100 of FIG. 1, etc.) being serviced by the context-aware network in FIG. 2 … The gathered data may be communicated via an ESB 204 (described in further detail below) and stored in a security access database 210; and Paragraph [0035]: operation 253 includes organizing/storing the gathered data into a security access database 210. The security access database 210 can be a collection of information that includes the gathered data (i.e., the identity data and the contextual data) organized in such a way that a computing device can select, process, and/or update desired pieces of data. A UBA logic/module 211 may use the gathered data in the security access database 210 for further processing. For example, and in one embodiment, the UBA logic/module 211 may process the gathered data using user behavior analytics (UBA) technologies to identify one or more patterns associated with user behaviors … For example, one UBA technique includes collecting and analyzing human behavior (e.g., network log-in times, network log-out times, geolocations associated with accessing a network, etc.) and then applying algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats).
The motivation to combine the arts is the same as that of Claim 2.
Regarding Claim 6:
The combination of Balazs, Tischart, and Ongpin teaches the method of claim 2.
Balazs further teaches further comprising: receiving, from the first user, a second resource access request (Balazs – Col. 10, Line 9-21: Once the user is properly authenticated, the method or the system may initiate a flow to fulfill the user's request for access to the financial management system at 312A. At 314A, the progression or traversal of the flow may be randomly, periodically, or continuously monitored by, for example, the level of assurance monitoring or enforcement module 112 to adaptively provide the adequate level of assurance based at least in part upon the sensitivity or criticality of the information to be presented to the user or action to be executed by the user. The method or system may the enhance the user experience while providing adequate security by using appropriate levels of assurance based at least in part upon the traversal of the flow at 316A) comprising the user identifier and a second activity for the second resource access request (Balazs – Col. 9, Line 27-40: The method or system may invoke a cyber-intelligence module at 304A and to identify one or more characteristics associated with the user's request at 306A to safeguard cybersecurity, computer security, or Internet fraud detection and prevention. In these embodiments, the one or more characteristics may include … the device identifications (e.g., media access control or MAC addresses) of the devices with which the user has used in issuing the requests; and Col. 20, Line 45-52: the method or system may further identify a change in the level of assurance upon receiving the user's request (e.g., by clicking or other types of user actions) to change the direct deposit account information or to access information including the user's taxpayer identification number (e.g., employer identification number, social security number, individual taxpayer identification number, etc.); Examiner’s Comment: this example demonstrates a resource access request which includes an activity for the request); determining an updated measure of risk to the system that is associated with executing the second resource access request for the first user (Balazs – Figure 3B: detailed flow of implementing adaptive levels of assurance to fulfill a user request; and Col. 11, Line 24-40: Optional risk assessment or management may also be performed to assess, rank, or manage potential risks or threats or to associate the potential risks or threats with various levels of assurance or security measures at 308B by using, for example the risk assessment or management process or module 118. More details about risk assessment or management are described in the subsequent paragraphs with reference to FIG. 4. At 310B, the method or system may optionally gather and analyze various analytics using the cyber-intelligence module to use various techniques including statistics, modeling, machine learning, or data mining to collect and analyze various types of current or historical data, information, or patterns to, for example, analyze or identify opportunities (e.g., customer satisfaction level in using the financial management system) or to identify or predict risks (e.g., the occurrence or likelihood of some future events); and Col. 12, Line 54-58: Based at least in part upon the identified potential threats or potential vulnerabilities, the method or system may identify or determine risks or levels of risks at 412 and map the identified or determined risks or levels of risks to appropriate levels of assurance at 414); and in response to determining that the updated measure of risk [is not below the threshold], processing the second resource access request for the second activity using the secured authentication token (Balazs – Col. 11, Line 41-56: Based at least in part upon the user's request, the one or more characteristics associated with the user's request, the results of risk assessment or management, or the results of analyzing analytics, the method or system may determine an appropriate authentication scheme at 312B. Upon the user's successful completion of the authentication and/or authorization processes, the method or system may then authorize the user to access at least a part of the financial management system that is associated with the current level of assurance as permitted or safeguarded by the identified authentication scheme at 314B. A flow may be initiated in response to the user's request at 316B, and the system or module may further monitor the traversal or progression of the flow for the user's session at 318B to ensure to provide adaptive levels of assurance as the user proceeds with the flow in the user's access to the financial management system).
Tischart teaches determining that the updated measure of risk is not below the threshold (Tischart – Paragraph [0036]: In at least one embodiment, operation 253 also includes providing the information stored in the security access database 210 to a context-aware decision logic/module 212, which may be part of the authentication entity 206 (as shown in FIG. 2). When a user of device 202A attempts to access a computer network (e.g., the network 100 of FIG. 1, etc.), the context-aware decision logic/module 212 uses the information associated with the current authentication session (i.e., the current identity data and the current contextual data being used for the current authentication session) and the data stored in the security access database 210 to determine a risk level associated with the current authentication session. If the risk level fails to exceed a threshold, the decision logic/module 212 does not trigger additional authentication sessions for the user of device 202. That is, the decision logic/module 212 will “inform” the authentication entity 206 to grant the user of device 202 access to the secure network based on the current authentication session (assuming the identity data used by the user of device 202 is in fact the correct information for successful authentication). Alternatively, if the risk level exceeds the threshold, the decision logic/module 212 triggers additional authentication sessions for the user of device 202A. Here, the decision logic/module 212 will cause the authentication entity 206 to request additional identity data from the user to establish confidence that the user is in fact who he/she claims to be).
The motivation to combine the arts is the same as that of Claim 2.
Regarding Claim 13:
Balazs teaches one or more non-transitory computer-readable storage media storing instructions that, when executed by one or more processors cause operations (Balazs – Col. 21, Line 35-41: According to one embodiment of the invention, computer system 900 performs specific operations by one or more processors or processor cores 907 executing one or more sequences of one or more instructions contained in system memory 908. Such instructions may be read into system memory 908 from another computer readable/usable storage medium, such as static storage device 909 or disk drive 910) comprising: receiving, from a first user, a resource access request for a system (Balazs – Col. 9, Line 20-25: the method or system may, at 302A, receive a user's request for access to a financial management system which may include, for example, a tax preparation product or service, an accounting product or service, a payroll product or service, or a personal or corporate finance product or service), wherein the resource access request comprises a user identifier and a first activity for the resource access request (Balazs – Col. 9, Line 27-40: The method or system may invoke a cyber-intelligence module at 304A and to identify one or more characteristics associated with the user's request at 306A to safeguard cybersecurity, computer security, or Internet fraud detection and prevention. In these embodiments, the one or more characteristics may include … the device identifications (e.g., media access control or MAC addresses) of the devices with which the user has used in issuing the requests; and Col. 20, Line 45-52: the method or system may further identify a change in the level of assurance upon receiving the user's request (e.g., by clicking or other types of user actions) to change the direct deposit account information or to access information including the user's taxpayer identification number (e.g., employer identification number, social security number, individual taxpayer identification number, etc.); Examiner’s Comment: this example demonstrates a resource access request which includes an activity for the request); retrieving information regarding authentication tokens associated with the first user usable to process the resource access request (Balazs – Col. 20, Line 25-30: One or more characteristics associated with the user's request may be identified at 806D. The method or system may identify a first authentication token based at least in part upon the user's request or the identified one or more characteristics associated with the user's request at 808D by using at least the cyber-intelligence process or module), the authentication tokens including a secured authentication token and an unsecured authentication token associated with the first user, wherein the unsecured authentication token is associated with higher priority resources compared to the secured authentication token (Balazs – Col. 20, Line 45-59: At 812D, the method or system may further identify a change in the level of assurance upon receiving the user's request (e.g., by clicking or other types of user actions) to change the direct deposit account information or to access information including the user's taxpayer identification number (e.g., employer identification number, social security number, individual taxpayer identification number, etc.). Assuming that the method or system determines that the user has not been authenticated to access such sensitive information, the method or system may further identify a second authentication token based at least in part upon the user's request to change direct deposit account information or to access the user's taxpayer identification number at 814D; and Col. 14, Line 35-46: Once the user is properly authenticated at an appropriate level of assurance associated with the adequate authentication scheme, the method or system may authorize the user to traverse the flow established in response to the user's request as far as the appropriate level of assurance permits at 512. For example, the user may be permitted to access the information or data or perform actions that are permitted by the appropriate level of assurance as well as lower levels of assurance associated with less sensitive, less confidential, or less critical information or data but is not permitted to access the information or data or perform actions that are permitted by higher levels of assurance; and Figure 8B: illustration of a plurality of tokens corresponding to varying levels of resource access; and Figure 7: illustration of levels of assurance granted by tiered tokens; Examiner’s Comment: The particular teaching in Column 14 of Balazs illustrates that a high-assurance token offers a user less-restricted or unrestricted access to system resources, corresponding to the description in the instant specification paragraph [0003], in which an unsecured system is described as: “with unsecured computer systems, known or vetted users may freely access and interact with the system without access control measures for different types of system resources. This setup can be more convenient and user-friendly, but it carries a higher risk of unauthorized access or potential misuse by unknown or lesser-known users”); determining that the user is associated with the secured authentication token and the unsecured authentication token (Balazs – Col. 20, Line 45-59: At 812D, the method or system may further identify a change in the level of assurance upon receiving the user's request (e.g., by clicking or other types of user actions) to change the direct deposit account information or to access information including the user's taxpayer identification number (e.g., employer identification number, social security number, individual taxpayer identification number, etc.). Assuming that the method or system determines that the user has not been authenticated to access such sensitive information, the method or system may further identify a second authentication token based at least in part upon the user's request to change direct deposit account information or to access the user's taxpayer identification number at 814D; and Col. 14, Line 35-46: Once the user is properly authenticated at an appropriate level of assurance associated with the adequate authentication scheme, the method or system may authorize the user to traverse the flow established in response to the user's request as far as the appropriate level of assurance permits at 512. For example, the user may be permitted to access the information or data or perform actions that are permitted by the appropriate level of assurance as well as lower levels of assurance associated with less sensitive, less confidential, or less critical information or data but is not permitted to access the information or data or perform actions that are permitted by higher levels of assurance; and Figure 8B: illustration of a plurality of tokens corresponding to varying levels of resource access; and Figure 7: illustration of levels of assurance granted by tiered tokens; Examiner’s Comment: The particular teaching in Column 14 of Balazs illustrates that a high-assurance token offers a user less-restricted or unrestricted access to system resources, corresponding to the description in the instant specification paragraph [0003], in which an unsecured system is described as: “with unsecured computer systems, known or vetted users may freely access and interact with the system without access control measures for different types of system resources. This setup can be more convenient and user-friendly, but it carries a higher risk of unauthorized access or potential misuse by unknown or lesser-known users”); in response to determining that the first user is associated with the secured authentication token and the unsecured authentication token, processing, using a machine learning model, and to determine a measure of risk, to the system, that is associated with executing the resource access request for the first activity for the first user, a resource access history (Balazs – Figure 3B: detailed flow of implementing adaptive levels of assurance to fulfill a user request; and Col. 9, Line 27-47: The method or system may invoke a cyber-intelligence module at 304A and to identify one or more characteristics associated with the user's request at 306A to safeguard cybersecurity, computer security, or Internet fraud detection and prevention. In these embodiments, the one or more characteristics may include, for example but not limited to, frequency of requests from the user such as the total number of requests from the user within a period of time, geographic locations in which the user has initiated the requests, network locations from which the user has initiated the requests, the device identifications (e.g., media access control or MAC addresses) of the devices with which the user has used in issuing the requests, actions of the user (e.g., merely browsing, copying, or printing information about personal information without actively attempting to further complete the flow), any other recognized or predicted behavior anomalies, or any combinations thereof. These one or more characteristics may be stored in one or more risk profiles or one or more policies referenced by various processes, modules, or systems described herein; and Col. 11, Line 24-40: Optional risk assessment or management may also be performed to assess, rank, or manage potential risks or threats or to associate the potential risks or threats with various levels of assurance or security measures at 308B by using, for example the risk assessment or management process or module 118. More details about risk assessment or management are described in the subsequent paragraphs with reference to FIG. 4. At 310B, the method or system may optionally gather and analyze various analytics using the cyber-intelligence module to use various techniques including statistics, modeling, machine learning, or data mining to collect and analyze various types of current or historical data, information, or patterns to, for example, analyze or identify opportunities (e.g., customer satisfaction level in using the financial management system) or to identify or predict risks (e.g., the occurrence or likelihood of some future events); and Col. 12, Line 54-58: Based at least in part upon the identified potential threats or potential vulnerabilities, the method or system may identify or determine risks or levels of risks at 412 and map the identified or determined risks or levels of risks to appropriate levels of assurance at 414); and in response to determining that the measure of risk [is not below a threshold], processing the resource access request for the first activity using the secured authentication token (Balazs – Col. 11, Line 41-56: Based at least in part upon the user's request, the one or more characteristics associated with the user's request, the results of risk assessment or management, or the results of analyzing analytics, the method or system may determine an appropriate authentication scheme at 312B. Upon the user's successful completion of the authentication and/or authorization processes, the method or system may then authorize the user to access at least a part of the financial management system that is associated with the current level of assurance as permitted or safeguarded by the identified authentication scheme at 314B. A flow may be initiated in response to the user's request at 316B, and the system or module may further monitor the traversal or progression of the flow for the user's session at 318B to ensure to provide adaptive levels of assurance as the user proceeds with the flow in the user's access to the financial management system).
Balazs does not expressly teach determining that the measure of risk is not below a threshold.
However, Tischart teaches determining that the measure of risk is not below a threshold (Tischart – Paragraph [0036]: In at least one embodiment, operation 253 also includes providing the information stored in the security access database 210 to a context-aware decision logic/module 212, which may be part of the authentication entity 206 (as shown in FIG. 2). When a user of device 202A attempts to access a computer network (e.g., the network 100 of FIG. 1, etc.), the context-aware decision logic/module 212 uses the information associated with the current authentication session (i.e., the current identity data and the current contextual data being used for the current authentication session) and the data stored in the security access database 210 to determine a risk level associated with the current authentication session. If the risk level fails to exceed a threshold, the decision logic/module 212 does not trigger additional authentication sessions for the user of device 202. That is, the decision logic/module 212 will “inform” the authentication entity 206 to grant the user of device 202 access to the secure network based on the current authentication session (assuming the identity data used by the user of device 202 is in fact the correct information for successful authentication). Alternatively, if the risk level exceeds the threshold, the decision logic/module 212 triggers additional authentication sessions for the user of device 202A. Here, the decision logic/module 212 will cause the authentication entity 206 to request additional identity data from the user to establish confidence that the user is in fact who he/she claims to be; and Paragraph [0004]: identity data can be broken up into three authentication factors … (ii) an ownership factor, which is a physical or virtual object possessed by the user (e.g., an identification card, a security token, a software token, a hardware token, a device with a hardware and/or software token, etc.)).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs, further incorporating Tischart to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Tischart’s teaching to evaluate a risk level against a threshold to determine whether a token is sufficient to grant a user secure access to system resources into Balazs’s system for managing resource access using tokens which grant varying levels of resource access. This combination enhances the system by providing a logical separator for different tiers of authentication (tokens) to allow corresponding different tiers of resource access securely and efficiently.
The combination of Balazs and Tischart does not expressly teach a resource access history that is based on a first access record regarding usage of the secured authentication token by the first user and based on a second access record regarding usage of the unsecured authentication token by the first user.
However, Ongpin teaches a resource access history that is based on a first access record regarding usage of the secured authentication token by the first user and based on a second access record regarding usage of the unsecured authentication token by the first user (Ongpin – Paragraph [0027] Thus, a first customer may have a first set of available authentication tokens, a second customer may have a second set of available authentication tokens, a third customer may have a third set of available authentication tokens, and so on. The authentication tokens that are available for each customer may be based upon the type of accounts associated with the customer, devices associated with the customer, and so forth. Paragraph [0054]: The customer data manager 108 may be configured to obtain data 408 related to the customer 404; and Paragraph [0055]: The data related to the customer may include customer level data and/or transaction level data. This data may include data such as, but not limited to, a date of a last challenge, the type of last challenge, whether the last challenge was successful, the number of times each of the authentication tokens were presented to the customer in a specific time frame, how many challenges were successful or failed over a period of time, and so on; and Paragraph [0056]: According to some implementations, the information related to the set of authentication tokens 402 and/or the customer data 408 may be retained in a central repository 410. For example, the authentication tokens available for a customer may be maintained in the central repository 410, as well as the available authentication tokens for other customers. Further, the data 408 related to the customer 404 (as well as other customers) may be stored in the central repository 410. In some implementations, the central repository 410 may be configured to retain current and future authentication methods available for each customer, as well as data related to the number of times each method has been presented to the customer and the result of the challenge (e.g., pass, fail); and Figure 7: illustration of a method for dynamic token-based access management based on user and token information/history; and Paragraph [0092]: FIG. 7 illustrates an example, non-limiting method 700 for entry point management, according to an aspect. The various aspects discussed herein allow for appropriate authentication methods to be presented to customers based on transaction type as well as authentication risk token score. Further, the various aspects provide dynamic authentication presentment challenges using previous challenge history and information. This may make it more difficult for bad actors and fraudsters to obtain access to accounts as the authentication challenge will not be predictable under the dynamic presentment. The ability to turn off certain authentication tokens in case of a compromise, including customer level compromises, is also provided. Further, additional authentication challenges (e.g., PIN plus AA OTP code) may be introduced if certain risk or score levels satisfy a threshold level. If a customer's authentication token risk score shows that the customer is at a low risk of compromise, a reduced authentication may be applied to that customer. In addition, the disclosed aspects may be enabled for other user types (e.g., guest, delegates), which may streamline development and authentication challenges).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs and Tischart, further incorporating Ongpin to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Ongpin’s teaching to consider historical usage data for different access tokens associated with a user for providing dynamically secured resource access into Balazs and Tischart’s combined system for managing resource access using tokens which grant varying levels of resource access. This additional functionality enhances the security of the system by determining a level of risk associated with a user and a plurality of tokens in real time, and requiring use of a token deemed appropriate for secure access based on recorded user-token activity.
Regarding Claim 14:
The combination of Balazs, Tischart, and Ongpin teaches the one or more non-transitory, computer-readable storage media of claim 13.
Balazs further teaches wherein the instructions further cause the one or more processors to perform operations comprising: receiving, from a second user (Balazs – Col. 5, Line 59-63: The software products or services provided to users may be installed on one or more of the plurality of remote computing devices 102, 104, or 106 or may be hosted in part or entirely on the computing system or cluster of computing systems 108), a second resource access request for the system (Balazs – Col. 9, Line 20-25: the method or system may, at 302A, receive a user's request for access to a financial management system which may include, for example, a tax preparation product or service, an accounting product or service, a payroll product or service, or a personal or corporate finance product or service), wherein the second resource access request comprises a second user identifier and a second activity for the second resource access request (Balazs – Col. 9, Line 27-40: The method or system may invoke a cyber-intelligence module at 304A and to identify one or more characteristics associated with the user's request at 306A to safeguard cybersecurity, computer security, or Internet fraud detection and prevention. In these embodiments, the one or more characteristics may include … the device identifications (e.g., media access control or MAC addresses) of the devices with which the user has used in issuing the requests; and Col. 20, Line 45-52: the method or system may further identify a change in the level of assurance upon receiving the user's request (e.g., by clicking or other types of user actions) to change the direct deposit account information or to access information including the user's taxpayer identification number (e.g., employer identification number, social security number, individual taxpayer identification number, etc.); Examiner’s Comment: this example demonstrates a resource access request which includes an activity for the request); determining that the second user is only associated with a second secured authentication token, wherein a risk associated with activities executed with the second secured authentication token is accommodated by the second user (Balazs – Col. 1, Line 47-67 and Col. 2, Line 1-2: The method associate various flow nodes in a flow for using a software product or service including the financial management system with one or more levels of assurance. The one or more levels of assurance are further associated with or mapped to some authentication tokens having different authentication strengths. When a user first requests to access the software product or service, the user may be first authenticated with a lower authentication strength token or even no authentication required. The method may optionally examine the request for access or one or more characteristics associated with the request for access to determine whether or not a heightened level of assurance having a higher authentication strength token than the lower authentication strength token is required or desired to authenticate and authorize the user issuing the request for access for fraud detection or fraud prevention purposes. The user may then be authorized to access the data or information or to perform actions permitted by the authorized level of assurance corresponding to the lower authentication strength token or no authentication. The user is thus not burdened by the more complex authentication efforts required by higher authentication tokens of higher authentication strengths); and processing the second resource access request for the second activity using the second secured authentication token (Balazs – Col. 1, Line 64-67: The user may then be authorized to access the data or information or to perform actions permitted by the authorized level of assurance corresponding to the lower authentication strength token or no authentication).
The motivation to combine the arts is the same as that of Claim 13.
Regarding Claim 15:
The combination of Balazs, Tischart, and Ongpin teaches the one or more non-transitory, computer-readable storage media of claim 13.
Tischart further teaches wherein processing the resource access history comprises: receiving, from a database, the resource access history for the first user (Tischart – Paragraph [0036]: In at least one embodiment, operation 253 also includes providing the information stored in the security access database 210 to a context-aware decision logic/module 212; and Paragraph [0032]: the context-aware authentication logic/module 201 gathers at least some of the data associated with authenticating a user of the device 202 that is attempting to gain access to the computer network (e.g., network 100 of FIG. 1, etc.) being serviced by the context-aware network in FIG. 2 … The gathered data may be communicated via an ESB 204 (described in further detail below) and stored in a security access database 210; and Paragraph [0035]: operation 253 includes organizing/storing the gathered data into a security access database 210. The security access database 210 can be a collection of information that includes the gathered data (i.e., the identity data and the contextual data) organized in such a way that a computing device can select, process, and/or update desired pieces of data. A UBA logic/module 211 may use the gathered data in the security access database 210 for further processing. For example, and in one embodiment, the UBA logic/module 211 may process the gathered data using user behavior analytics (UBA) technologies to identify one or more patterns associated with user behaviors … For example, one UBA technique includes collecting and analyzing human behavior (e.g., network log-in times, network log-out times, geolocations associated with accessing a network, etc.) and then applying algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats).
The motivation to combine the arts is the same as that of Claim 13.
Regarding Claim 17:
The combination of Balazs, Tischart, and Ongpin teaches the one or more non-transitory, computer-readable storage media of claim 13.
Balazs further teaches wherein the instructions further cause the one or more processors to perform operations comprising: receiving, from the first user, a second resource access request for a system (Balazs – Col. 10, Line 9-21: Once the user is properly authenticated, the method or the system may initiate a flow to fulfill the user's request for access to the financial management system at 312A. At 314A, the progression or traversal of the flow may be randomly, periodically, or continuously monitored by, for example, the level of assurance monitoring or enforcement module 112 to adaptively provide the adequate level of assurance based at least in part upon the sensitivity or criticality of the information to be presented to the user or action to be executed by the user. The method or system may the enhance the user experience while providing adequate security by using appropriate levels of assurance based at least in part upon the traversal of the flow at 316A), wherein the second resource access request comprises the user identifier and a second activity for the second resource access request (Balazs – Col. 9, Line 27-40: The method or system may invoke a cyber-intelligence module at 304A and to identify one or more characteristics associated with the user's request at 306A to safeguard cybersecurity, computer security, or Internet fraud detection and prevention. In these embodiments, the one or more characteristics may include … the device identifications (e.g., media access control or MAC addresses) of the devices with which the user has used in issuing the requests; and Col. 20, Line 45-52: the method or system may further identify a change in the level of assurance upon receiving the user's request (e.g., by clicking or other types of user actions) to change the direct deposit account information or to access information including the user's taxpayer identification number (e.g., employer identification number, social security number, individual taxpayer identification number, etc.); Examiner’s Comment: this example demonstrates a resource access request which includes an activity for the request); determining an updated measure of risk to the system that is associated with executing the second resource access request for the first user (Balazs – Figure 3B: detailed flow of implementing adaptive levels of assurance to fulfill a user request; and Col. 11, Line 24-40: Optional risk assessment or management may also be performed to assess, rank, or manage potential risks or threats or to associate the potential risks or threats with various levels of assurance or security measures at 308B by using, for example the risk assessment or management process or module 118. More details about risk assessment or management are described in the subsequent paragraphs with reference to FIG. 4. At 310B, the method or system may optionally gather and analyze various analytics using the cyber-intelligence module to use various techniques including statistics, modeling, machine learning, or data mining to collect and analyze various types of current or historical data, information, or patterns to, for example, analyze or identify opportunities (e.g., customer satisfaction level in using the financial management system) or to identify or predict risks (e.g., the occurrence or likelihood of some future events); and Col. 12, Line 54-58: Based at least in part upon the identified potential threats or potential vulnerabilities, the method or system may identify or determine risks or levels of risks at 412 and map the identified or determined risks or levels of risks to appropriate levels of assurance at 414); and in response to determining that the updated measure of risk [is not below the threshold], processing the second resource access request for the second activity using the secured authentication token (Balazs – Col. 11, Line 41-56: Based at least in part upon the user's request, the one or more characteristics associated with the user's request, the results of risk assessment or management, or the results of analyzing analytics, the method or system may determine an appropriate authentication scheme at 312B. Upon the user's successful completion of the authentication and/or authorization processes, the method or system may then authorize the user to access at least a part of the financial management system that is associated with the current level of assurance as permitted or safeguarded by the identified authentication scheme at 314B. A flow may be initiated in response to the user's request at 316B, and the system or module may further monitor the traversal or progression of the flow for the user's session at 318B to ensure to provide adaptive levels of assurance as the user proceeds with the flow in the user's access to the financial management system).
Tischart teaches determining that the updated measure of risk is not below the threshold (Tischart – Paragraph [0036]: In at least one embodiment, operation 253 also includes providing the information stored in the security access database 210 to a context-aware decision logic/module 212, which may be part of the authentication entity 206 (as shown in FIG. 2). When a user of device 202A attempts to access a computer network (e.g., the network 100 of FIG. 1, etc.), the context-aware decision logic/module 212 uses the information associated with the current authentication session (i.e., the current identity data and the current contextual data being used for the current authentication session) and the data stored in the security access database 210 to determine a risk level associated with the current authentication session. If the risk level fails to exceed a threshold, the decision logic/module 212 does not trigger additional authentication sessions for the user of device 202. That is, the decision logic/module 212 will “inform” the authentication entity 206 to grant the user of device 202 access to the secure network based on the current authentication session (assuming the identity data used by the user of device 202 is in fact the correct information for successful authentication). Alternatively, if the risk level exceeds the threshold, the decision logic/module 212 triggers additional authentication sessions for the user of device 202A. Here, the decision logic/module 212 will cause the authentication entity 206 to request additional identity data from the user to establish confidence that the user is in fact who he/she claims to be).
The motivation to combine the arts is the same as that of Claim 13.
Claim(s) 5, 11, and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Balazs in view of Tischart, Ongpin and Handelman (US 20210326881 A1), hereinafter Handelman.
Regarding Claim 5:
The combination of Balazs, Tischart, and Ongpin teaches the method of claim 2.
Ongpin further teaches wherein the plurality of resource access records include the first access record and the second access record (Ongpin – Paragraph [0055]: The data related to the customer may include customer level data and/or transaction level data. This data may include data such as, but not limited to, a date of a last challenge, the type of last challenge, whether the last challenge was successful, the number of times each of the authentication tokens were presented to the customer in a specific time frame, how many challenges were successful or failed over a period of time, and so on).
The combination of Balazs, Tischart, and Ongpin does not expressly teach wherein processing the resource access history comprises: determining an amount associated with the first activity for the resource access request; transmitting a request to a database for a plurality of resource access records for the amount associated with the first activity for the resource access request; and processing the plurality of resource access records using the machine learning model to determine the measure of risk associated with executing the resource access request for the first activity for the first user.
However, Handelman teaches wherein processing the resource access history comprises: determining an amount associated with the first activity for the resource access request (Handelman – Paragraph [0043]: Prior to processing the transaction request, the interface server 134 may transmit, to the risk determination module 132, a request for assessing a risk associated with the user 140 and/or the transaction based on the transaction request. The request may include an identity of the user 140 and attributes associated with the transaction (e.g., an amount, an identity of the merchant, etc.)); transmitting a request to a database for a plurality of resource access records for the amount associated with the first activity for the resource access request (Handelman – Paragraph [0043]: The request may include an identity of the user 140 and attributes associated with the transaction (e.g., an amount, an identity of the merchant, etc.). Upon receiving the request from the interface server 134, the risk manager 202 may retrieve data associated with the user 140 from the account database 136. In some embodiments, the risk manager 202 may retrieve data associated with transactions previously conducted by the user 140 over a period of time (e.g., the past year, the past month, the past three months, etc.) from the account database 136. The risk manager 202 may then use the document generation module 204 to generate a text document (e.g., a risk document) 240 for the user 140 based on the data associated with the previous transactions; and Paragraph [0047]: While the text document 240 in this example is shown to include only the names of the merchants, in some embodiments, the document generation module 204 may insert word(s) associated with one or more different types of data of the previous transactions (e.g., amounts, products/services purchased, locations of the transactions, etc.) in addition to the names or instead of the names); and processing the plurality of resource access records using the machine learning model to determine the measure of risk associated with executing the resource access request for the first activity for the first user (Handelman – Paragraph [0052]: when the risk manager provides the topic model 206 with the text document 240, the topic model 206 may analyze the words to produce a topic classification; and Paragraph [0055]: The risk determination module 132 may use the topic classification to assess a risk associated with the user 140 and/or the transaction initiated by the user 140).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs, Tischart, and Ongpin, further incorporating Handelman to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Handelman’s teaching to use a machine learning model to determine a risk level of an access request based on an amount associated with access records into Balazs, Tischart, and Ongpin’s method for managing resource access using tokens which grant varying levels of resource access. This addition would further enhance the system by providing a more specifically targeted risk assessment in a more specific risk scenario.
Regarding Claim 11:
The combination of Balazs, Tischart, and Ongpin teaches the method of claim 2.
Tischart further teaches wherein processing the resource access history comprises: receiving, from a database, the resource access history corresponding to the first user (Tischart – Paragraph [0036]: In at least one embodiment, operation 253 also includes providing the information stored in the security access database 210 to a context-aware decision logic/module 212; and Paragraph [0032]: the context-aware authentication logic/module 201 gathers at least some of the data associated with authenticating a user of the device 202 that is attempting to gain access to the computer network (e.g., network 100 of FIG. 1, etc.) being serviced by the context-aware network in FIG. 2 … The gathered data may be communicated via an ESB 204 (described in further detail below) and stored in a security access database 210; and Paragraph [0035]: operation 253 includes organizing/storing the gathered data into a security access database 210. The security access database 210 can be a collection of information that includes the gathered data (i.e., the identity data and the contextual data) organized in such a way that a computing device can select, process, and/or update desired pieces of data. A UBA logic/module 211 may use the gathered data in the security access database 210 for further processing. For example, and in one embodiment, the UBA logic/module 211 may process the gathered data using user behavior analytics (UBA) technologies to identify one or more patterns associated with user behaviors … For example, one UBA technique includes collecting and analyzing human behavior (e.g., network log-in times, network log-out times, geolocations associated with accessing a network, etc.) and then applying algorithms and statistical analysis to detect meaningful anomalies from those patterns—anomalies that indicate potential threats).
The combination of Balazs, Tischart, and Ongpin does not expressly teach wherein the resource access history comprises a plurality of resource access records corresponding to the first user (Handelman – Paragraph [0043]: The request may include an identity of the user 140 and attributes associated with the transaction (e.g., an amount, an identity of the merchant, etc.). Upon receiving the request from the interface server 134, the risk manager 202 may retrieve data associated with the user 140 from the account database 136. In some embodiments, the risk manager 202 may retrieve data associated with transactions previously conducted by the user 140 over a period of time (e.g., the past year, the past month, the past three months, etc.) from the account database 136); identifying a provider associated with the first activity for the resource access request (Handelman – Paragraph [0043]: The request may include an identity of the user 140 and attributes associated with the transaction (e.g., an amount, an identity of the merchant, etc.)); searching each resource access record in the plurality of resource access records associated with the provider (Handelman – Paragraph [0046]: In some embodiments, the document generation module 204 inserts the word(s) associated with each previous transaction into the text document 240 even though the words already appear in the text document 240. For example, since the user 140 has purchased from the merchant “Best_Buy” three times in the particular time period, the document generation module 204 inserts the word “Best_Buy” into the text document 240 three times); and determining, using the machine learning model, the measure of risk based on the provider (Handelman – Paragraph [0053]: In this example where the identities (e.g., names) of the merchants or sellers involved in the previous transactions are used to generate the text document 240, the topic model 260 may classify the text document into topics that may correspond to different types of merchants … the topic model 206 may be configured to classify different text or risk documents to different topic classifications (e.g., different probability distributions across the different topics) based on the different words (corresponding to different merchants) included in the risk documents; and Paragraph [0055]: The risk determination module 132 may use the topic classification to assess a risk associated with the user 140 and/or the transaction initiated by the user 140).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs, Tischart, and Ongpin, further incorporating Handelman to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Handelman’s teaching to use a machine learning model to determine a risk level of an access request based on a provider associated with the requested resource into Balazs, Tischart, and Ongpin’s method for managing resource access using tokens which grant varying levels of resource access. This addition would further enhance the system by providing another specifically targeted risk assessment.
Regarding Claim 16:
The combination of Balazs, Tischart, and Ongpin teaches the one or more non-transitory, computer-readable storage media of claim 13.
Ongpin further teaches wherein the plurality of resource access records include the first access record and the second access record (Ongpin – Paragraph [0055]: The data related to the customer may include customer level data and/or transaction level data. This data may include data such as, but not limited to, a date of a last challenge, the type of last challenge, whether the last challenge was successful, the number of times each of the authentication tokens were presented to the customer in a specific time frame, how many challenges were successful or failed over a period of time, and so on).
The combination of Balazs, Tischart, and Ongpin does not expressly teach wherein processing the resource access history comprises: determining an amount associated with the first activity for the resource access request; transmitting a request to a database for a plurality of resource access records for the amount associated with the first activity for the resource access request; and processing the plurality of resource access records using the machine learning model to determine the measure of risk associated with executing the resource access request for the first activity for the first user.
However, Handelman teaches wherein processing the resource access history comprises: determining an amount associated with the first activity for the resource access request (Handelman – Paragraph [0043]: Prior to processing the transaction request, the interface server 134 may transmit, to the risk determination module 132, a request for assessing a risk associated with the user 140 and/or the transaction based on the transaction request. The request may include an identity of the user 140 and attributes associated with the transaction (e.g., an amount, an identity of the merchant, etc.)); transmitting a request to a database for a plurality of resource access records for the amount associated with the first activity for the resource access request (Handelman – Paragraph [0043]: The request may include an identity of the user 140 and attributes associated with the transaction (e.g., an amount, an identity of the merchant, etc.). Upon receiving the request from the interface server 134, the risk manager 202 may retrieve data associated with the user 140 from the account database 136. In some embodiments, the risk manager 202 may retrieve data associated with transactions previously conducted by the user 140 over a period of time (e.g., the past year, the past month, the past three months, etc.) from the account database 136. The risk manager 202 may then use the document generation module 204 to generate a text document (e.g., a risk document) 240 for the user 140 based on the data associated with the previous transactions; and Paragraph [0047]: While the text document 240 in this example is shown to include only the names of the merchants, in some embodiments, the document generation module 204 may insert word(s) associated with one or more different types of data of the previous transactions (e.g., amounts, products/services purchased, locations of the transactions, etc.) in addition to the names or instead of the names); and processing the plurality of resource access records using the machine learning model to determine the measure of risk associated with executing the resource access request for the first activity for the first user (Handelman – Paragraph [0052]: when the risk manager provides the topic model 206 with the text document 240, the topic model 206 may analyze the words to produce a topic classification; and Paragraph [0055]: The risk determination module 132 may use the topic classification to assess a risk associated with the user 140 and/or the transaction initiated by the user 140).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs, Tischart, and Ongpin, further incorporating Handelman to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Handelman’s teaching to use a machine learning model to determine a risk level of an access request based on an amount associated with access records into Balazs, Tischart, and Ongpin’s method for managing resource access using tokens which grant varying levels of resource access. This addition would further enhance the system by providing a more specifically targeted risk assessment in a more specific risk scenario.
Claim(s) 7 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Balazs in view of Tischart, Ongpin, and Bondeson (US 20150254656 A1), hereinafter Bondeson.
Regarding Claim 7:
The combination of Balazs, Tischart, and Ongpin teaches the method of claim 6.
The combination of Balazs, Tischart, and Ongpin does not expressly teach determining an amount limit corresponding to the secured authentication token associated with the first user; and updating the amount limit after processing the resource access request for the first activity using the secured authentication token.
However, Bondeson teaches determining an amount limit corresponding to the secured authentication token associated with the first user (Bondeson – Paragraph [0042]: The tokenization service 50 may also store limits (e.g., geographic limits, transaction amount limits, merchant limits, product limits, any other limit described herein, or the like) associated with the token that may limit the transactions in which the user 2 may enter); and updating the amount limit after processing the resource access request for the first activity using the secured authentication token (Bondeson – Paragraph [0097]: If the first token parameters limits the use of the token to a certain number of uses or amounts for a time period (e.g., a day), the first token may fall outside of the first token parameters if the token has already been used by other users during the designated time period; Examiner’s Comment: an update of an amount limit of a token is inherent in a token which has a daily limit for the number of times/amounts the token can be used).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs, Tischart, and Ongpin, further incorporating Bondeson to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Bondeson’s teaching to implement limits for using different tokens for resource access into Balazs, Tischart, and Ongpin’s method for managing resource access using tokens which grant varying levels of resource access. This combination would provide further security by adding another mechanism to prevent, or at least limit, unauthorized/fraudulent use of resources.
Regarding Claim 18:
The combination of Balazs, Tischart, and Ongpin teaches the one or more non-transitory, computer-readable storage media of claim 17.
The combination of Balazs, Tischart, and Ongpin does not expressly teach wherein the instructions further cause the one or more processors to perform operations comprising: determining an amount limit corresponding to the secured authentication token associated with the first user; and updating the amount limit after processing the resource access request for the first activity using the secured authentication token.
However, Bondeson teaches wherein the instructions further cause the one or more processors to perform operations comprising: determining an amount limit corresponding to the secured authentication token associated with the first user (Bondeson – Paragraph [0042]: The tokenization service 50 may also store limits (e.g., geographic limits, transaction amount limits, merchant limits, product limits, any other limit described herein, or the like) associated with the token that may limit the transactions in which the user 2 may enter); and updating the amount limit after processing the resource access request for the first activity using the secured authentication token (Bondeson – Paragraph [0097]: If the first token parameters limits the use of the token to a certain number of uses or amounts for a time period (e.g., a day), the first token may fall outside of the first token parameters if the token has already been used by other users during the designated time period; Examiner’s Comment: an update of an amount limit of a token is inherent in a token which has a daily limit for the number of times/amounts the token can be used).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs, Tischart, and Ongpin, further incorporating Bondeson to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Bondeson’s teaching to implement limits for using different tokens for resource access into Balazs, Tischart, and Ongpin’s method for managing resource access using tokens which grant varying levels of resource access. This combination would provide further security by adding another mechanism to prevent, or at least limit, unauthorized/fraudulent use of resources.
Claim(s) 8 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Balazs in view of Tischart, Ongpin, and Phillips et al. (US 20210272083 A1), hereinafter Phillips.
Regarding Claim 8:
The combination of Balazs, Tischart, and Ongpin teaches the method of claim 2.
The combination of Balazs, Tischart, and Ongpin does not expressly teach wherein processing the resource access history comprises: transmitting a request to determine an available amount of resources corresponding to the first user; and in response to determining the available amount of resources corresponding to the first user is less than an amount associated with the first activity, determining the measure of risk is higher than the threshold.
However, Phillips teaches wherein processing the resource access history comprises: transmitting a request to determine an available amount of resources corresponding to the first user (Phillips – Paragraph [0057]: In some implementations, account matching platform 230 may receive information when a user of user device 210 registers with account matching platform 230, when a user of user device 210 inputs the information (e.g., via a user interface of user device 210), based on requesting the information (e.g., from server device 220 and/or a user of user device 210), and/or the like; and Paragraph [0063]: information related to potential account users may identify each of the potential account users … an amount of money in an account associated with the potential account user); and in response to determining the available amount of resources corresponding to the first user is less than an amount associated with the first activity, determining the measure of risk is higher than the threshold (Phillips – Paragraph [0076]: account matching platform 230 may determine an offer based on … a risk associated with a transaction for an account owner of an account to be used to complete the transaction (e.g., whether account matching platform 230 has verified that the potential account user using the account has money to repay the transaction, a credit score for a potential account user that is to use the account, etc.); and Paragraph [0082]: account matching platform 230 may determine a match based on an amount of a transaction satisfying a threshold (e.g., indicating a threshold level of risk associated with the transaction), being associated with an amount of benefits that satisfies a threshold, whether an amount associated with a transaction is less than an amount of credit remaining for a line of credit of the account owner, and/or the like; and Paragraph [0146]: Some implementations are described herein in connection with thresholds. As used herein, satisfying a threshold may refer to a value being greater than the threshold, more than the threshold, higher than the threshold, greater than or equal to the threshold, less than the threshold, fewer than the threshold, lower than the threshold, less than or equal to the threshold, equal to the threshold, or the like).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs and Tischart, further incorporating Phillips to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Phillips’s teaching to make request risk determinations based on available amounts compared to requested amounts into Balazs and Tischart’s method for managing resource access using tokens which grant varying levels of resource access. This addition enhances the system with another layer of risk mitigation in evaluating access requests.
Regarding Claim 9:
The combination of Balazs, Tischart, and Ongpin teaches the method of claim 2.
The combination of Balazs, Tischart, and Ongpin does not expressly teach wherein processing the resource access history comprises: transmitting a request to determine an available amount of resources corresponding to the first user; and in response to determining the available amount of resources corresponding to the first user is less than an amount associated with the first activity, determining the measure of risk is higher than the threshold.
However, Phillips teaches wherein processing the resource access history comprises: transmitting a request to determine an available amount of resources corresponding to the first user (Phillips – Paragraph [0057]: In some implementations, account matching platform 230 may receive information when a user of user device 210 registers with account matching platform 230, when a user of user device 210 inputs the information (e.g., via a user interface of user device 210), based on requesting the information (e.g., from server device 220 and/or a user of user device 210), and/or the like; and Paragraph [0063]: information related to potential account users may identify each of the potential account users … an amount of money in an account associated with the potential account user); and in response to determining the available amount of resources corresponding to the first user is less than an amount associated with the first activity, determining the measure of risk is lower than the threshold (Phillips – Paragraph [0076]: account matching platform 230 may determine an offer based on … a risk associated with a transaction for an account owner of an account to be used to complete the transaction (e.g., whether account matching platform 230 has verified that the potential account user using the account has money to repay the transaction, a credit score for a potential account user that is to use the account, etc.); and Paragraph [0082]: account matching platform 230 may determine a match based on an amount of a transaction satisfying a threshold (e.g., indicating a threshold level of risk associated with the transaction), being associated with an amount of benefits that satisfies a threshold, whether an amount associated with a transaction is less than an amount of credit remaining for a line of credit of the account owner, and/or the like; and Paragraph [0146]: Some implementations are described herein in connection with thresholds. As used herein, satisfying a threshold may refer to a value being greater than the threshold, more than the threshold, higher than the threshold, greater than or equal to the threshold, less than the threshold, fewer than the threshold, lower than the threshold, less than or equal to the threshold, equal to the threshold, or the like).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs and Tischart, further incorporating Phillips to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Phillips’s teaching to make request risk determinations based on available amounts compared to requested amounts into Balazs and Tischart’s method for managing resource access using tokens which grant varying levels of resource access. This addition enhances the system with another layer of risk mitigation in evaluating access requests.
Claim(s) 10 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Balazs in view of Tischart, Ongpin, and Swift (US 6308274 B1), hereinafter Swift.
Regarding Claim 10:
The combination of Balazs, Tischart, and Ongpin teaches the method of claim 2.
Balazs further teaches further comprising: receiving, from a user device associated with the first user, a pre-access request (Balazs – Col. 9, Line 20-25: the method or system may, at 302A, receive a user's request for access to a financial management system which may include, for example, a tax preparation product or service, an accounting product or service, a payroll product or service, or a personal or corporate finance product or service), wherein the pre-access request comprises a user identifier and an activity for the pre-access request (Balazs – Col. 9, Line 27-40: The method or system may invoke a cyber-intelligence module at 304A and to identify one or more characteristics associated with the user's request at 306A to safeguard cybersecurity, computer security, or Internet fraud detection and prevention. In these embodiments, the one or more characteristics may include … the device identifications (e.g., media access control or MAC addresses) of the devices with which the user has used in issuing the requests; and Col. 20, Line 45-52: the method or system may further identify a change in the level of assurance upon receiving the user's request (e.g., by clicking or other types of user actions) to change the direct deposit account information or to access information including the user's taxpayer identification number (e.g., employer identification number, social security number, individual taxpayer identification number, etc.); Examiner’s Comment: this example demonstrates a resource access request which includes an activity for the request which is received/transmitted prior to accessing the requested resource).
The combination of Balazs, Tischart, and Ongpin does not expressly teach and generating a notification to the user device, wherein the notification comprises whether the system processes the resource access request with the unsecured authentication token or the secured authentication token for the activity.
However, Swift teaches and generating a notification to the user device, wherein the notification comprises whether the system processes the resource access request with the unsecured authentication token or the secured authentication token for the activity (Swift – Figure 11: flow diagram illustrating provision of resources based on tokens; and Col. 14, Line 16-65: at step 1102, the restricted token is associated with the user's restricted process. As also shown at step 1102, when the process attempts to access a resource, an access evaluation is performed, using the restricted token against the security descriptor of the resource … if at step 1104 access is not allowed, instead of denying access, the operating system may give the user an additional opportunity to access the resource using a token with increased access … if the token has a parent at step 1106, the system prompts the user at step 1110 to determine whether the user wants to try accessing the resource again at an increased access level, i.e., with the restricted token's parent token).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs, Tischart, and Ongpin, further incorporating Swift to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Swift’s teaching to prompt a user to perform higher-risk, higher-priority tasks with appropriate access tokens into Balazs, Tischart, and Ongpin’s method for managing resource access using tokens which grant varying levels of resource access. This functionality provides insight for system users into the use of tokens for their corresponding activities.
Regarding Claim 19:
The combination of Balazs, Tischart, and Ongpin teaches the one or more non-transitory, computer-readable storage media of claim 13.
Balazs further teaches wherein the instructions further cause the one or more processors to perform operations comprising: receiving, from a user device associated with the first user, a pre-access request (Balazs – Col. 9, Line 20-25: the method or system may, at 302A, receive a user's request for access to a financial management system which may include, for example, a tax preparation product or service, an accounting product or service, a payroll product or service, or a personal or corporate finance product or service), wherein the pre-access request comprises a user identifier and an activity for the pre-access request (Balazs – Col. 9, Line 27-40: The method or system may invoke a cyber-intelligence module at 304A and to identify one or more characteristics associated with the user's request at 306A to safeguard cybersecurity, computer security, or Internet fraud detection and prevention. In these embodiments, the one or more characteristics may include … the device identifications (e.g., media access control or MAC addresses) of the devices with which the user has used in issuing the requests; and Col. 20, Line 45-52: the method or system may further identify a change in the level of assurance upon receiving the user's request (e.g., by clicking or other types of user actions) to change the direct deposit account information or to access information including the user's taxpayer identification number (e.g., employer identification number, social security number, individual taxpayer identification number, etc.); Examiner’s Comment: this example demonstrates a resource access request which includes an activity for the request which is received/transmitted prior to accessing the requested resource).
The combination of Balazs, Tischart, and Ongpin does not expressly teach and generating a notification to the user device, wherein the notification comprises whether the system processes the resource access request with the unsecured authentication token or the secured authentication token for the activity.
However, Swift teaches and generating a notification to the user device, wherein the notification comprises whether the system processes the resource access request with the unsecured authentication token or the secured authentication token for the activity (Swift – Figure 11: flow diagram illustrating provision of resources based on tokens; and Col. 14, Line 16-65: at step 1102, the restricted token is associated with the user's restricted process. As also shown at step 1102, when the process attempts to access a resource, an access evaluation is performed, using the restricted token against the security descriptor of the resource … if at step 1104 access is not allowed, instead of denying access, the operating system may give the user an additional opportunity to access the resource using a token with increased access … if the token has a parent at step 1106, the system prompts the user at step 1110 to determine whether the user wants to try accessing the resource again at an increased access level, i.e., with the restricted token's parent token).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs, Tischart, and Ongpin, further incorporating Swift to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Swift’s teaching to prompt a user to perform higher-risk, higher-priority tasks with appropriate access tokens into Balazs, Tischart, and Ongpin’s method for managing resource access using tokens which grant varying levels of resource access. This functionality provides insight for system users into the use of tokens for their corresponding activities.
Claim(s) 12 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Balazs in view of Tischart, Ongpin, and Adam et al. (US 11855997 B1), hereinafter Adam.
Regarding Claim 12:
The combination of Balazs, Tischart, and Ongpin teaches the method of claim 2.
Balazs further teaches and in response to identifying the first activity [as the periodic activity] updating the measure of risk (Balazs – Figure 3B: detailed flow of implementing adaptive levels of assurance to fulfill a user request; and Col. 11, Line 24-40: Optional risk assessment or management may also be performed to assess, rank, or manage potential risks or threats or to associate the potential risks or threats with various levels of assurance or security measures at 308B by using, for example the risk assessment or management process or module 118. More details about risk assessment or management are described in the subsequent paragraphs with reference to FIG. 4. At 310B, the method or system may optionally gather and analyze various analytics using the cyber-intelligence module to use various techniques including statistics, modeling, machine learning, or data mining to collect and analyze various types of current or historical data, information, or patterns to, for example, analyze or identify opportunities (e.g., customer satisfaction level in using the financial management system) or to identify or predict risks (e.g., the occurrence or likelihood of some future events); and Col. 12, Line 54-58: Based at least in part upon the identified potential threats or potential vulnerabilities, the method or system may identify or determine risks or levels of risks at 412 and map the identified or determined risks or levels of risks to appropriate levels of assurance at 414).
The combination of Balazs, Tischart, and Ongpin does not expressly teach further comprising: identifying the first activity as a periodic activity, wherein the periodic activity occurs within a certain timeframe; and identifying the first activity as the periodic activity.
However, Adam teaches further comprising: identifying the first activity as a periodic activity, wherein the periodic activity occurs within a certain timeframe (Adam – Figure 5: Table illustrating time durations associated with requested resources; and Col. 14, Line 3-14: As seen in FIG. 5, the available initial access request times may vary depending on the computer resource. A minimum time duration, which may be a minimum time duration request increment, may be provided. For example, an initial access request time period may be 30 minutes, 5 minutes, etc. A maximum time duration, which may be a multiple of a minimum time duration request increment, may also be provided. The minimum and maximum time durations may vary depending on the resource identity, such as based on an average time for a task using the computer resource, relative security threat to the computer resource, etc); and identifying the first activity as a periodic activity (Adam – Figure 5: Table illustrating time durations associated with requested resources; and Col. 14, Line 3-14: As seen in FIG. 5, the available initial access request times may vary depending on the computer resource. A minimum time duration, which may be a minimum time duration request increment, may be provided. For example, an initial access request time period may be 30 minutes, 5 minutes, etc. A maximum time duration, which may be a multiple of a minimum time duration request increment, may also be provided. The minimum and maximum time durations may vary depending on the resource identity, such as based on an average time for a task using the computer resource, relative security threat to the computer resource, etc).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs, Tischart, and Ongpin, further incorporating Adam to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Adam’s time-limited access requests into Balazs, Tischart, and Ongpin’s method for managing resource access using tokens which grant varying levels of resource access. This combination provides an additional built-in security mechanism to limit potential abuse of resources.
Regarding Claim 20:
The combination of Balazs, Tischart, and Ongpin teaches the one or more non-transitory, computer-readable storage media of claim 13.
Balazs further teaches and in response to identifying the first activity [as the periodic activity] updating the measure of risk (Balazs – Figure 3B: detailed flow of implementing adaptive levels of assurance to fulfill a user request; and Col. 11, Line 24-40: Optional risk assessment or management may also be performed to assess, rank, or manage potential risks or threats or to associate the potential risks or threats with various levels of assurance or security measures at 308B by using, for example the risk assessment or management process or module 118. More details about risk assessment or management are described in the subsequent paragraphs with reference to FIG. 4. At 310B, the method or system may optionally gather and analyze various analytics using the cyber-intelligence module to use various techniques including statistics, modeling, machine learning, or data mining to collect and analyze various types of current or historical data, information, or patterns to, for example, analyze or identify opportunities (e.g., customer satisfaction level in using the financial management system) or to identify or predict risks (e.g., the occurrence or likelihood of some future events); and Col. 12, Line 54-58: Based at least in part upon the identified potential threats or potential vulnerabilities, the method or system may identify or determine risks or levels of risks at 412 and map the identified or determined risks or levels of risks to appropriate levels of assurance at 414).
The combination of Balazs, Tischart, and Ongpin does not expressly teach wherein the instructions further cause the one or more processors to perform operations comprising: identifying the first activity as a periodic activity, wherein the periodic activity occurs within a certain timeframe; and identifying the first activity as the periodic activity.
However, Adam teaches wherein the instructions further cause the one or more processors to perform operations comprising: identifying the first activity as a periodic activity, wherein the periodic activity occurs within a certain timeframe (Adam – Figure 5: Table illustrating time durations associated with requested resources; and Col. 14, Line 3-14: As seen in FIG. 5, the available initial access request times may vary depending on the computer resource. A minimum time duration, which may be a minimum time duration request increment, may be provided. For example, an initial access request time period may be 30 minutes, 5 minutes, etc. A maximum time duration, which may be a multiple of a minimum time duration request increment, may also be provided. The minimum and maximum time durations may vary depending on the resource identity, such as based on an average time for a task using the computer resource, relative security threat to the computer resource, etc); and identifying the first activity as the periodic activity (Adam – Figure 5: Table illustrating time durations associated with requested resources; and Col. 14, Line 3-14: As seen in FIG. 5, the available initial access request times may vary depending on the computer resource. A minimum time duration, which may be a minimum time duration request increment, may be provided. For example, an initial access request time period may be 30 minutes, 5 minutes, etc. A maximum time duration, which may be a multiple of a minimum time duration request increment, may also be provided. The minimum and maximum time durations may vary depending on the resource identity, such as based on an average time for a task using the computer resource, relative security threat to the computer resource, etc).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Balazs, Tischart, and Ongpin, further incorporating Adam to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Adam’s time-limited access requests into Balazs, Tischart, and Ongpin’s method for managing resource access using tokens which grant varying levels of resource access. This combination provides an additional built-in security mechanism to limit potential abuse of resources.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Alnajem (US 20170300911 A1) teaches a system for evaluating risk associated with performing a transaction for a user, considering authentication information provided by the user in combination with performance statistics
Robinson et al. (US 11546358 B1) teaches a system for managing access tokens for services, wherein a plurality of tokens provide access to resources based on a policies associated with the tokens and user
Mohamed (US 10528939 B2) teaches a system and methods for completing transactions using user-provided tokens, including evaluating whether a provided token is compromised and requiring use of a separate, secured token when the provided token is compromised
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 PM.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/NICHOLAS JOSEPH DILUZIO/Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights