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 .
Summary
This action is a responsive to the application filed on 7/31/2024.
Claims 1-20 are pending and have been examined.
Claims 1-20 are rejected.
Response to Arguments
Rejection of Claims under 35 USC 101
Applicant’s Response:
Independent claims 1, 12, and 20 were rejected under 35 U.S.C. § 101 as allegedly being directed to an abstract idea without significantly more. See Office Action, p. 2. In particular, the Office Action alleges that "generating a report" is "a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind (mental process)," and that "nothing in the claim element precludes the step from practically being performed in the mind." Id. Without conceding the merits of the rejection under 35 U.S.C. § 101-and solely to expedite prosecution-Applicant has amended independent claims 1, 12, and 20. For example, amended independent claim 1 recites "outputting, via a user interface, a report indicative of a second plurality of applications accessed via user profiles of the organization, a plurality of user profiles that accessed the second plurality of applications, and a timestamp of access to the second plurality of applications by each of the plurality of user profiles," which cannot practically be performed in the human mind. For example, the human mind is not equipped to output "via a user interface, a report" as recited in amended independent claim 1. Independent claims 12 and 20 have been amended to include similar features. Therefore, for at least these reasons, independent claims 1, 12, and 20 do not recite a mental process, nor do independent claims 1, 12, and 20 recite any other abstract idea, law of nature, or natural phenomenon. Accordingly, Applicant requests that the rejection of independent claims 1, 12, and 20 under 35 U.S.C. § 101 be reconsidered and withdrawn.
Examiner’s Response:
Applicant’s arguments, see remarks, filed 6/23/26, with respect to claims 1-20 have been fully considered and are persuasive. The rejection of 3/25/26 has been withdrawn.
Rejection of Claims under 35 USC 102
Applicant’s Response:
Applicant submits that the cited references fail to teach the newly added limitations of:
wherein the one or more signals are received based at least in part on the sign-in to the first application using the first user profile of the organization.
Examiner’s Response:
Applicant’s arguments with respect to claims 1, 12, 20 have been considered but are moot because the arguments are directed to amended subject matter properly addressed with the newly cited reference of WADHWA et al. (US 20240176855 A1).
The combination of Kirti et al. (US 20170251013 A1) and WADHWA et al. (US 20240176855 A1) teaches the language of the independent claims.
All remaining arguments are now moot in regards to the new rejection.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3-7, 10-12, 14-18, 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kirti et al. (US 20170251013 A1) and further in view of WADHWA et al. (US 20240176855 A1).
As to claim 1, Kirti et al. teaches a method for managing application access by an organization via an identity management system, comprising: receiving one or more signals associated with a sign-in to a first application using a first user profile of the organization, wherein the first application is disassociated with a first plurality of applications having been authorized access by an administrator of the organization via the identity management system (See ¶¶ [0168]-[0173], Teaches that Flowchart 1100 may begin at step 1102 by obtaining information about network activity of a user. The information may be obtained from data obtained using techniques for monitoring network activity, including those disclosed with reference to FIG. 8. Data about network activity may be obtained by monitoring and/or obtaining data (e.g., log data or record data) from network devices. For an organization to monitor application usage, an organization may monitor its internal, or protected network (e.g., Intranet) for network activity. Network activity may be monitored by obtaining information from network resources (e.g., a network device) of network traffic within and external to the network of the organization. At step 1106, access information is determined for each of the one or more applications that have been accessed. The access information may be determined using the information obtained at step 1102. An application may be identified by processing the data to identify a portion of the data corresponding to a request for the application accessed by the user. The portion of the data may indicates application information about the request for the application, the application information being used to identify the application as being accessed by the user.);
outputting, via a user interface, a report indicative of a second plurality of applications accessed via user profiles of the organization, a plurality of user profiles that accessed the second plurality of applications, and a timestamp of access to the second plurality of applications by each of the plurality of user profiles, wherein the second plurality of applications comprise at least the first application, and wherein the plurality of user profiles comprise at least the first user profile (See ¶¶ [0183], [0168]-[0173], [0011], Teaches that In some embodiments, at step 1116, a display may be provided to display information about each of the one or more applications that have been accessed. The display may be a graphical interface that is provided in an application or a web browser. The display may be interactive to monitor and manage security of the applications. The display may be generated by security monitoring and control system 102. Providing the display may include causing the display to be rendered at a client. Upon generation, the display may be sent to a client to be rendered. Examples of various interactive displays are disclosed with reference to FIGS. 15-26. In some embodiments, a display may be provided as a report in a message sent to a client. The report may be a notification about security related to an application. The access information may include network information about a request to access the application, including information about a source (e.g., a source device) requesting the application and a destination to which the request is sent. The access information may include, without restriction, a timestamp of the network activity, application information (e.g., application name, a source location to access the application, and/or details about the application), an IP address of a source, an IP address of a destination, geolocation information about the source, user information (e.g., user identification or email identification), and a media access control (MAC) address. A source location of an application can be a link, such as a URL, or an URI. The information obtained at step 1102 can be processed to identify network activity with regard to each unique application identified at step 1104. The graphical interface may be interactive to configure remediation actions to be performed based on a security policy with respect to each security risk. For organizations having difficulty in identifying and managing security risks by unknown usage of applications, the graphical interface can enable an organization to efficiently and reliably discover all if not most application usage to minimize security risks and maximize resource consumption of computing-related resources in a computing environment.);
and performing, via a user interface, an application management operation associated with at least one application of the second plurality of applications, at least one user profile of the plurality of user profiles, or both based at least in part on outputting the report via the user interface (See ¶¶ [0184]-[0190], [0011], Teaches that At step 1118, one or more remediation actions may be performed for each of the one or more accessed applications. A remediation action is an action performed on a remedial or corrective basis to address a security (e.g., a security risk or a threat) posed by an application. Examples of remediation action, include without limitation, sending a notification message about security of an application, displaying information about security of an application, adjusting operation and/or access of an application (e.g., restrictive adjustment of access). The graphical interface may be interactive to configure remediation actions to be performed based on a security policy with respect to each security risk. For organizations having difficulty in identifying and managing security risks by unknown usage of applications, the graphical interface can enable an organization to efficiently and reliably discover all if not most application usage to minimize security risks and maximize resource consumption of computing-related resources in a computing environment.).
However, it does not expressly teach the details of wherein the one or more signals are received based at least in part on the sign-in to the first application using the first user profile of the organization.
WADHWA et al., from analogous art, teaches wherein the one or more signals are received based at least in part on the sign-in to the first application using the first user profile of the organization (See ¶¶ [0087]-[0091], Teaches that According to embodiments of the present disclosure, the integrated identity management and monitoring system may be configured to maintain detailed logs and records of every event or interaction occurring in the system. These events or interactions may be associated with authenticating user credentials, user profile changes, role assignments or changes in role definitions, and new application registrations. For example, user access of application, responses from the identity providers, storing and retrieving data from the encrypted data vault, authentication events, user account or user information changes, changes in a user's role assignment, new client registrations, or unusual system restarts may be examples of events that may be logged or recorded. Logging or recording each such event and interaction enables rapid detection of faults or unusual system activity. Further, rapid detection also allows efficient and immediate troubleshooting of the faults or unusual activity detected. In some embodiments, these events or interactions may be transmitted or published to the observation framework 128. In some embodiments, detailed logs may be generated related to events associated with the authenticating. In the same or other embodiments, generating detailed logs may include logging actions performed during the authenticating, user profile changes, role assignments, and new application registrations. In some embodiments, the generated logs may be used to generate a dashboard on a user interface or a user device to display overall system performance, resource utilization, alarms, alerts, and interface with the security operations personnel. In some embodiments, the metrics displayed on the generated dashboard may include but not be limited to: The total number of users created, number of logins per user identity provider, number of logins per client application, number of login errors for each client application, number of login errors for a single realm, memory usage, etc. According to embodiments, either the observation framework 128 or the integrated identity management and monitoring system may generate the dashboard on the user management UI 110 or user device 210).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of WADHWA et al. into Kirti et al. in order to generate detailed logs related to events associated with the authenticating; analyze the generated logs; and generate an alarm based on the analyzing of the generated logs (See WADHWA et al. ¶ [0013]).
As to claim 3, the combination of Kirti et al. and WADHWA et al. teaches the method according to claim 1 above. Kirti et al. further teaches wherein performing the application management operation comprises revoking access to the at least one application (See ¶¶ [0184]-[0185], Teaches that At step 1118, one or more remediation actions may be performed for each of the one or more accessed applications. A remediation action is an action performed on a remedial or corrective basis to address a security (e.g., a security risk or a threat) posed by an application. Examples of remediation action, include without limitation, sending a notification message about security of an application, displaying information about security of an application, adjusting operation and/or access of an application (e.g., restrictive adjustment of access). For example, controlling access for an application may include blocking or preventing a user or group of users from accessing the application. Limiting, blocking or preventing access to an application may be achieved in many ways. One or more instructions can be sent or configured to adjust access for an application.).
As to claim 4, the combination of Kirti et al. and WADHWA et al. teaches the method according to claim 3 above. Kirti et al. further teaches further comprising: receiving, via an administrator dashboard of the identity management system, one or more second signals associated with revoking access to the at least one application (See ¶¶ [0184]-[0185], [0112], Teaches that At step 1118, one or more remediation actions may be performed for each of the one or more accessed applications. A remediation action is an action performed on a remedial or corrective basis to address a security (e.g., a security risk or a threat) posed by an application. Examples of remediation action, include without limitation, sending a notification message about security of an application, displaying information about security of an application, adjusting operation and/or access of an application (e.g., restrictive adjustment of access). For example, controlling access for an application may include blocking or preventing a user or group of users from accessing the application. Limiting, blocking or preventing access to an application may be achieved in many ways. One or more instructions can be sent or configured to adjust access for an application. Examples of reports that can be generated include, but are not limited to, login statistics (e.g., users with the most failed logins, IP address based login history including consideration of IP reputation, geolocation, and other factors), user statistics (e.g., users with the most resources [files, EC2 machines, etc.], entitlements across clouds, number of changed passwords), activity statistics (e.g., activity of a user across clouds), statistics on key rotation (e.g., whether SSH keys have been rotated within the last 30 days), and resource statistics (e.g., number of folders, files downloaded by users, files downloaded by roaming or mobile users).).
As to claim 5, the combination of Kirti et al. and WADHWA et al. teaches the method according to claim 3 above. Kirti et al. further teaches further comprising: receiving one or more second signals associated with a sign-in attempt to the at least one application, wherein the sign-in attempt is unsuccessful based at least in part on revoking access to the at least one application (See ¶¶ [0184]-[0185], [0112], Teaches that At step 1118, one or more remediation actions may be performed for each of the one or more accessed applications. A remediation action is an action performed on a remedial or corrective basis to address a security (e.g., a security risk or a threat) posed by an application. Examples of remediation action, include without limitation, sending a notification message about security of an application, displaying information about security of an application, adjusting operation and/or access of an application (e.g., restrictive adjustment of access). For example, controlling access for an application may include blocking or preventing a user or group of users from accessing the application. Limiting, blocking or preventing access to an application may be achieved in many ways. One or more instructions can be sent or configured to adjust access for an application. Examples of reports that can be generated include, but are not limited to, login statistics (e.g., users with the most failed logins, IP address based login history including consideration of IP reputation, geolocation, and other factors), user statistics (e.g., users with the most resources [files, EC2 machines, etc.], entitlements across clouds, number of changed passwords), activity statistics (e.g., activity of a user across clouds), statistics on key rotation (e.g., whether SSH keys have been rotated within the last 30 days), and resource statistics (e.g., number of folders, files downloaded by users, files downloaded by roaming or mobile users).).
As to claim 6, the combination of Kirti et al. and WADHWA et al. teaches the method according to claim 1 above. Kirti et al. further teaches wherein the application management operation is performed based at least in part on a threshold quantity of user profiles accessing the at least one application (See ¶¶ [0243], [0184]-[0185], [0112], Teaches that In some embodiments, an entry may indicate other information about events related to the discovered application. An entry may indicate information about use of the application, such as the number of users that have accessed the application and a date when the application was accessed. At step 1118, one or more remediation actions may be performed for each of the one or more accessed applications. A remediation action is an action performed on a remedial or corrective basis to address a security (e.g., a security risk or a threat) posed by an application. Examples of remediation action, include without limitation, sending a notification message about security of an application, displaying information about security of an application, adjusting operation and/or access of an application (e.g., restrictive adjustment of access). For example, controlling access for an application may include blocking or preventing a user or group of users from accessing the application. Limiting, blocking or preventing access to an application may be achieved in many ways. One or more instructions can be sent or configured to adjust access for an application. Examples of reports that can be generated include, but are not limited to, login statistics (e.g., users with the most failed logins, IP address based login history including consideration of IP reputation, geolocation, and other factors), user statistics (e.g., users with the most resources [files, EC2 machines, etc.], entitlements across clouds, number of changed passwords), activity statistics (e.g., activity of a user across clouds), statistics on key rotation (e.g., whether SSH keys have been rotated within the last 30 days), and resource statistics (e.g., number of folders, files downloaded by users, files downloaded by roaming or mobile users).).
As to claim 7, the combination of Kirti et al. and WADHWA et al. teaches the method according to claim 1 above. Kirti et al. further teaches further comprising: transmitting one or more application programming interface (API) calls to a provider associated with the user profiles of the organization, wherein generating the report indicative of the second plurality of applications accessed via the user profiles of the organization is based at least in part on transmitting the one or more API calls (See ¶¶ [0065], [0092], [0183], [0168]-[0173], Teaches that Security monitoring and control system 102 may provide web-based client interfaces, dedicated application programs, application program interfaces (APIs), graphical interfaces, communication interfaces, and/or other tools for facilitating communication between client devices 106 and security monitoring and control system 102.).
As to claim 10, the combination of Kirti et al. and WADHWA et al. teaches the method according to claim 1 above. Kirti et al. further teaches wherein the one or more signals comprise a domain of the first application (See ¶ [0128], Teaches that At 728, processing may be performed to determine information about third-party apps that have been accessed. The apps events may be used to determine unique information identifying each application. Using the information about the application, security monitoring and control system 102 may compute an application risk score for the application using techniques disclosed herein. In some embodiments, an app risk score registry 704 may be maintained from which an application risk score may be obtained. The registry may be maintained and automatically updated based on new and/or updated information about application usage. An application risk score may be computed based on application details and risk score indicators from a risk score feed 740 obtained using a third party source, such as a third-party app registry 706. Application details may include vendor information about a service provider, or vendor that provides the third-party application. Vendor information may include vendor name, vendor logo, vendor domain, vendor description, vendor category (business), and/or a security indicator (e.g., a score or a link to access security score evaluation supporting data). The information about an application may be sent at 730 to client console 702 for display in a graphical interface such as one depicted in FIG. 15.).
As to claim 11, the combination of Kirti et al. and WADHWA et al. teaches the method according to claim 1 above. Kirti et al. further teaches wherein the application management operation is determined via an artificial intelligence model (See ¶ [0051], Teaches that security monitoring and control system 102 analyzes information about user activity in one or more clouds using machine learning and other algorithms to perform threat detection and to provide recommendations concerning appropriate responses to different categories of threat. The analytics can include determining models of normal and/or abnormal behavior in user activity and detecting patterns of suspicious activity in one cloud or across multiple clouds. Some patterns may involve detecting the same action or different actions in multiple clouds that are associated with the same user account or IP address. Analytics may also include providing an alert and recommending remedial measures in the cloud(s) in which suspicious activity is detected and/or remedial measures to be taken in clouds other than those showing suspicious activity. In many embodiments of this disclosure, processes for detecting and analyzing applications on devices within a network of an organization involve collecting and combining information from various data sources.).
As to claim 12, Kirti et al. teaches an identity management system for managing application access by an organization, comprising: one or more memories storing processor-executable code; and one or more processors coupled with the one or more memories and individually or collectively operable to execute the code to cause the identity management system to: receive one or more signals associated with a sign-in to a first application using a first user profile of the organization, wherein the first application is disassociated with a first plurality of applications having been authorized access by an administrator of the organization via the identity management system (See ¶¶ [0168]-[0173], Teaches that Flowchart 1100 may begin at step 1102 by obtaining information about network activity of a user. The information may be obtained from data obtained using techniques for monitoring network activity, including those disclosed with reference to FIG. 8. Data about network activity may be obtained by monitoring and/or obtaining data (e.g., log data or record data) from network devices. For an organization to monitor application usage, an organization may monitor its internal, or protected network (e.g., Intranet) for network activity. Network activity may be monitored by obtaining information from network resources (e.g., a network device) of network traffic within and external to the network of the organization. At step 1106, access information is determined for each of the one or more applications that have been accessed. The access information may be determined using the information obtained at step 1102. An application may be identified by processing the data to identify a portion of the data corresponding to a request for the application accessed by the user. The portion of the data may indicates application information about the request for the application, the application information being used to identify the application as being accessed by the user.);
output, via a user interface, a report indicative of a second plurality of applications accessed via user profiles of the organization, a plurality of user profiles that accessed the second plurality of applications, and a timestamp of access to the second plurality of applications by each of the plurality of user profiles, wherein the second plurality of applications comprise at least the first application, and wherein the plurality of user profiles comprise at least the first user profile (See ¶¶ [0183], [0168]-[0173], [0011], Teaches that In some embodiments, at step 1116, a display may be provided to display information about each of the one or more applications that have been accessed. The display may be a graphical interface that is provided in an application or a web browser. The display may be interactive to monitor and manage security of the applications. The display may be generated by security monitoring and control system 102. Providing the display may include causing the display to be rendered at a client. Upon generation, the display may be sent to a client to be rendered. Examples of various interactive displays are disclosed with reference to FIGS. 15-26. In some embodiments, a display may be provided as a report in a message sent to a client. The report may be a notification about security related to an application. The access information may include network information about a request to access the application, including information about a source (e.g., a source device) requesting the application and a destination to which the request is sent. The access information may include, without restriction, a timestamp of the network activity, application information (e.g., application name, a source location to access the application, and/or details about the application), an IP address of a source, an IP address of a destination, geolocation information about the source, user information (e.g., user identification or email identification), and a media access control (MAC) address. A source location of an application can be a link, such as a URL, or an URI. The information obtained at step 1102 can be processed to identify network activity with regard to each unique application identified at step 1104. The graphical interface may be interactive to configure remediation actions to be performed based on a security policy with respect to each security risk. For organizations having difficulty in identifying and managing security risks by unknown usage of applications, the graphical interface can enable an organization to efficiently and reliably discover all if not most application usage to minimize security risks and maximize resource consumption of computing-related resources in a computing environment);
and perform, via the user interface, an application management operation associated with at least one application of the second plurality of applications, at least one user profile of the plurality of user profiles, or both based at least in part on outputting the report via the user interface (See ¶¶ [0184]-[0190], [0011], Teaches that At step 1118, one or more remediation actions may be performed for each of the one or more accessed applications. A remediation action is an action performed on a remedial or corrective basis to address a security (e.g., a security risk or a threat) posed by an application. Examples of remediation action, include without limitation, sending a notification message about security of an application, displaying information about security of an application, adjusting operation and/or access of an application (e.g., restrictive adjustment of access). The graphical interface may be interactive to configure remediation actions to be performed based on a security policy with respect to each security risk. For organizations having difficulty in identifying and managing security risks by unknown usage of applications, the graphical interface can enable an organization to efficiently and reliably discover all if not most application usage to minimize security risks and maximize resource consumption of computing-related resources in a computing environment).
However, it does not expressly teach the details of wherein the one or more signals are received based at least in part on the sign-in to the first application using the first user profile of the organization.
WADHWA et al., from analogous art, teaches wherein the one or more signals are received based at least in part on the sign-in to the first application using the first user profile of the organization (See ¶¶ [0087]-[0091], Teaches that According to embodiments of the present disclosure, the integrated identity management and monitoring system may be configured to maintain detailed logs and records of every event or interaction occurring in the system. These events or interactions may be associated with authenticating user credentials, user profile changes, role assignments or changes in role definitions, and new application registrations. For example, user access of application, responses from the identity providers, storing and retrieving data from the encrypted data vault, authentication events, user account or user information changes, changes in a user's role assignment, new client registrations, or unusual system restarts may be examples of events that may be logged or recorded. Logging or recording each such event and interaction enables rapid detection of faults or unusual system activity. Further, rapid detection also allows efficient and immediate troubleshooting of the faults or unusual activity detected. In some embodiments, these events or interactions may be transmitted or published to the observation framework 128. In some embodiments, detailed logs may be generated related to events associated with the authenticating. In the same or other embodiments, generating detailed logs may include logging actions performed during the authenticating, user profile changes, role assignments, and new application registrations. In some embodiments, the generated logs may be used to generate a dashboard on a user interface or a user device to display overall system performance, resource utilization, alarms, alerts, and interface with the security operations personnel. In some embodiments, the metrics displayed on the generated dashboard may include but not be limited to: The total number of users created, number of logins per user identity provider, number of logins per client application, number of login errors for each client application, number of login errors for a single realm, memory usage, etc. According to embodiments, either the observation framework 128 or the integrated identity management and monitoring system may generate the dashboard on the user management UI 110 or user device 210).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of WADHWA et al. into Kirti et al. in order to generate detailed logs related to events associated with the authenticating; analyze the generated logs; and generate an alarm based on the analyzing of the generated logs (See WADHWA et al. ¶ [0013]).
As to claim 14, the combination of Kirti et al. and WADHWA et al. teaches the system according to claim 12 above. Kirti et al. further teaches wherein performing the application management operation comprises revoking access to the at least one application (See ¶¶ [0184]-[0185], Teaches that At step 1118, one or more remediation actions may be performed for each of the one or more accessed applications. A remediation action is an action performed on a remedial or corrective basis to address a security (e.g., a security risk or a threat) posed by an application. Examples of remediation action, include without limitation, sending a notification message about security of an application, displaying information about security of an application, adjusting operation and/or access of an application (e.g., restrictive adjustment of access). For example, controlling access for an application may include blocking or preventing a user or group of users from accessing the application. Limiting, blocking or preventing access to an application may be achieved in many ways. One or more instructions can be sent or configured to adjust access for an application.).
As to claim 15, the combination of Kirti et al. and WADHWA et al. teaches the system according to claim 14 above. Kirti et al. further teaches wherein the one or more processors are individually or collectively further operable to execute the code to cause the identity management system to: receive, via an administrator dashboard of the identity management system, one or more second signals associated with revoking access to the at least one application (See ¶¶ [0184]-[0185], [0112], Teaches that At step 1118, one or more remediation actions may be performed for each of the one or more accessed applications. A remediation action is an action performed on a remedial or corrective basis to address a security (e.g., a security risk or a threat) posed by an application. Examples of remediation action, include without limitation, sending a notification message about security of an application, displaying information about security of an application, adjusting operation and/or access of an application (e.g., restrictive adjustment of access). For example, controlling access for an application may include blocking or preventing a user or group of users from accessing the application. Limiting, blocking or preventing access to an application may be achieved in many ways. One or more instructions can be sent or configured to adjust access for an application. Examples of reports that can be generated include, but are not limited to, login statistics (e.g., users with the most failed logins, IP address based login history including consideration of IP reputation, geolocation, and other factors), user statistics (e.g., users with the most resources [files, EC2 machines, etc.], entitlements across clouds, number of changed passwords), activity statistics (e.g., activity of a user across clouds), statistics on key rotation (e.g., whether SSH keys have been rotated within the last 30 days), and resource statistics (e.g., number of folders, files downloaded by users, files downloaded by roaming or mobile users).).
As to claim 16, the combination of Kirti et al. and WADHWA et al. teaches the system according to claim 14 above. Kirti et al. further teaches wherein the one or more processors are individually or collectively further operable to execute the code to cause the identity management system to: receive one or more second signals associated with a sign-in attempt to the at least one application, wherein the sign-in attempt is unsuccessful based at least in part on revoking access to the at least one application (See ¶¶ [0184]-[0185], [0112], Teaches that At step 1118, one or more remediation actions may be performed for each of the one or more accessed applications. A remediation action is an action performed on a remedial or corrective basis to address a security (e.g., a security risk or a threat) posed by an application. Examples of remediation action, include without limitation, sending a notification message about security of an application, displaying information about security of an application, adjusting operation and/or access of an application (e.g., restrictive adjustment of access). For example, controlling access for an application may include blocking or preventing a user or group of users from accessing the application. Limiting, blocking or preventing access to an application may be achieved in many ways. One or more instructions can be sent or configured to adjust access for an application. Examples of reports that can be generated include, but are not limited to, login statistics (e.g., users with the most failed logins, IP address based login history including consideration of IP reputation, geolocation, and other factors), user statistics (e.g., users with the most resources [files, EC2 machines, etc.], entitlements across clouds, number of changed passwords), activity statistics (e.g., activity of a user across clouds), statistics on key rotation (e.g., whether SSH keys have been rotated within the last 30 days), and resource statistics (e.g., number of folders, files downloaded by users, files downloaded by roaming or mobile users).).
As to claim 17, the combination of Kirti et al. and WADHWA et al. teaches the system according to claim 12 above. Kirti et al. further teaches wherein the application management operation is performed based at least in part on a threshold quantity of user profiles accessing the at least one application (See ¶¶ [0243], [0184]-[0185], [0112], Teaches that In some embodiments, an entry may indicate other information about events related to the discovered application. An entry may indicate information about use of the application, such as the number of users that have accessed the application and a date when the application was accessed. At step 1118, one or more remediation actions may be performed for each of the one or more accessed applications. A remediation action is an action performed on a remedial or corrective basis to address a security (e.g., a security risk or a threat) posed by an application. Examples of remediation action, include without limitation, sending a notification message about security of an application, displaying information about security of an application, adjusting operation and/or access of an application (e.g., restrictive adjustment of access). For example, controlling access for an application may include blocking or preventing a user or group of users from accessing the application. Limiting, blocking or preventing access to an application may be achieved in many ways. One or more instructions can be sent or configured to adjust access for an application. Examples of reports that can be generated include, but are not limited to, login statistics (e.g., users with the most failed logins, IP address based login history including consideration of IP reputation, geolocation, and other factors), user statistics (e.g., users with the most resources [files, EC2 machines, etc.], entitlements across clouds, number of changed passwords), activity statistics (e.g., activity of a user across clouds), statistics on key rotation (e.g., whether SSH keys have been rotated within the last 30 days), and resource statistics (e.g., number of folders, files downloaded by users, files downloaded by roaming or mobile users).).
As to claim 18, the combination of Kirti et al. and WADHWA et al. teaches the system according to claim 12 above. Kirti et al. further teaches wherein the one or more processors are individually or collectively further operable to execute the code to cause the identity management system to: transmit one or more application programming interface (API) calls to a provider associated with the user profiles of the organization, wherein generating the report indicative of the second plurality of applications accessed via the user profiles of the organization is based at least in part on transmitting the one or more API calls (See ¶¶ [0065], [0092], [0183], [0168]-[0173], Teaches that Security monitoring and control system 102 may provide web-based client interfaces, dedicated application programs, application program interfaces (APIs), graphical interfaces, communication interfaces, and/or other tools for facilitating communication between client devices 106 and security monitoring and control system 102.).
As to claim 20, Kirti et al. teaches a non-transitory computer-readable medium storing code for managing application access, the code comprising instructions executable by one or more processors to: receive one or more signals associated with a sign-in to a first application using a first user profile of an organization, wherein the first application is disassociated with a first plurality of applications having been authorized access by an administrator of the organization via an identity management system (See ¶¶ [0168]-[0173], Teaches that Flowchart 1100 may begin at step 1102 by obtaining information about network activity of a user. The information may be obtained from data obtained using techniques for monitoring network activity, including those disclosed with reference to FIG. 8. Data about network activity may be obtained by monitoring and/or obtaining data (e.g., log data or record data) from network devices. For an organization to monitor application usage, an organization may monitor its internal, or protected network (e.g., Intranet) for network activity. Network activity may be monitored by obtaining information from network resources (e.g., a network device) of network traffic within and external to the network of the organization. At step 1106, access information is determined for each of the one or more applications that have been accessed. The access information may be determined using the information obtained at step 1102. An application may be identified by processing the data to identify a portion of the data corresponding to a request for the application accessed by the user. The portion of the data may indicates application information about the request for the application, the application information being used to identify the application as being accessed by the user.);
output, via s user interface, a report indicative of a second plurality of applications accessed via user profiles of the organization, a plurality of user profiles that accessed the second plurality of applications, and a timestamp of access to the second plurality of applications by each of the plurality of user profiles, wherein the second plurality of applications comprise at least the first application, and wherein the plurality of user profiles comprise at least the first user profile (See ¶¶ [0183], [0168]-[0173], [0011], Teaches that In some embodiments, at step 1116, a display may be provided to display information about each of the one or more applications that have been accessed. The display may be a graphical interface that is provided in an application or a web browser. The display may be interactive to monitor and manage security of the applications. The display may be generated by security monitoring and control system 102. Providing the display may include causing the display to be rendered at a client. Upon generation, the display may be sent to a client to be rendered. Examples of various interactive displays are disclosed with reference to FIGS. 15-26. In some embodiments, a display may be provided as a report in a message sent to a client. The report may be a notification about security related to an application. The access information may include network information about a request to access the application, including information about a source (e.g., a source device) requesting the application and a destination to which the request is sent. The access information may include, without restriction, a timestamp of the network activity, application information (e.g., application name, a source location to access the application, and/or details about the application), an IP address of a source, an IP address of a destination, geolocation information about the source, user information (e.g., user identification or email identification), and a media access control (MAC) address. A source location of an application can be a link, such as a URL, or an URI. The information obtained at step 1102 can be processed to identify network activity with regard to each unique application identified at step 1104. The graphical interface may be interactive to configure remediation actions to be performed based on a security policy with respect to each security risk. For organizations having difficulty in identifying and managing security risks by unknown usage of applications, the graphical interface can enable an organization to efficiently and reliably discover all if not most application usage to minimize security risks and maximize resource consumption of computing-related resources in a computing environment);
and perform, via the user interface, an application management operation associated with at least one application of the second plurality of applications, at least one user profile of the plurality of user profiles, or both based at least in part on outputting the report via the user interface (See ¶¶ [0184]-[0190], [0011], Teaches that At step 1118, one or more remediation actions may be performed for each of the one or more accessed applications. A remediation action is an action performed on a remedial or corrective basis to address a security (e.g., a security risk or a threat) posed by an application. Examples of remediation action, include without limitation, sending a notification message about security of an application, displaying information about security of an application, adjusting operation and/or access of an application (e.g., restrictive adjustment of access). The graphical interface may be interactive to configure remediation actions to be performed based on a security policy with respect to each security risk. For organizations having difficulty in identifying and managing security risks by unknown usage of applications, the graphical interface can enable an organization to efficiently and reliably discover all if not most application usage to minimize security risks and maximize resource consumption of computing-related resources in a computing environment).
However, it does not expressly teach the details of wherein the one or more signals are received based at least in part on the sign-in to the first application using the first user profile of the organization.
WADHWA et al., from analogous art, teaches wherein the one or more signals are received based at least in part on the sign-in to the first application using the first user profile of the organization (See ¶¶ [0087]-[0091], Teaches that According to embodiments of the present disclosure, the integrated identity management and monitoring system may be configured to maintain detailed logs and records of every event or interaction occurring in the system. These events or interactions may be associated with authenticating user credentials, user profile changes, role assignments or changes in role definitions, and new application registrations. For example, user access of application, responses from the identity providers, storing and retrieving data from the encrypted data vault, authentication events, user account or user information changes, changes in a user's role assignment, new client registrations, or unusual system restarts may be examples of events that may be logged or recorded. Logging or recording each such event and interaction enables rapid detection of faults or unusual system activity. Further, rapid detection also allows efficient and immediate troubleshooting of the faults or unusual activity detected. In some embodiments, these events or interactions may be transmitted or published to the observation framework 128. In some embodiments, detailed logs may be generated related to events associated with the authenticating. In the same or other embodiments, generating detailed logs may include logging actions performed during the authenticating, user profile changes, role assignments, and new application registrations. In some embodiments, the generated logs may be used to generate a dashboard on a user interface or a user device to display overall system performance, resource utilization, alarms, alerts, and interface with the security operations personnel. In some embodiments, the metrics displayed on the generated dashboard may include but not be limited to: The total number of users created, number of logins per user identity provider, number of logins per client application, number of login errors for each client application, number of login errors for a single realm, memory usage, etc. According to embodiments, either the observation framework 128 or the integrated identity management and monitoring system may generate the dashboard on the user management UI 110 or user device 210).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of WADHWA et al. into Kirti et al. in order to generate detailed logs related to events associated with the authenticating; analyze the generated logs; and generate an alarm based on the analyzing of the generated logs (See WADHWA et al. ¶ [0013]).
Claims 2, 9, 13 are rejected under 35 U.S.C. 103 as being unpatentable over Kirti et al. (US 20170251013 A1) and WADHWA et al. (US 20240176855 A1) and further in view of Jadhav et al. (US 20200007555 A1).
As to claim 2, the combination of Kirti et al. and WADHWA et al. teaches the method according to claim 1 above. However, it does not expressly teach the details of wherein performing the application management operation comprises: configuring, by the administrator of the organization via the identity management system, the at least one application to have authorized access, wherein the first plurality of applications comprises the at least one application based at least in part on configuring the at least one application to have authorized access.
Jadhav et al., from analogous art, teaches wherein performing the application management operation comprises: configuring, by the administrator of the organization via the identity management system, the at least one application to have authorized access, wherein the first plurality of applications comprises the at least one application based at least in part on configuring the at least one application to have authorized access (See ¶¶ [0021]-[0023], Teaches that the IAM tool employs a unified IAM database, such as a version of Active Directory, that stores a user profile for one or more users. The user profile can specify the access rights for the user in one or more of the various applications on the platform, including whether or not the user is authorized to access an application and, if so, the access rights (e.g., privileges) of the user in that application. For example, access rights can include whether the user has viewer privileges (e.g., as a normal, non-administrative user) or administrative privileges. The IAM database can provide for the centralized management of users and/or user groups across multiple applications. In some implementations, an organizational unit (OU) can be specified in the database for each application. The OU can include any appropriate number of users groups, which each define a particular set of access rights for the particular application. If a user is a member of a user group, that can indicate that the user has the corresponding access rights to the corresponding application as specified by the user group. The IAM tool can connect to the IAM database and access the various defined OUs in the database. Based on the access rights defined by the user groups in the OUs, and based on the users who are designated (e.g., in their user profiles) as members of various user group(s), the IAM tool can propagate the access rights for each user to the appropriate applications in the platform. In this way, the IAM tool can provide centralized user identity and access rights management for all the applications in the platform. In some implementations, a user profile can be a record stored in the unified IAM database. The user profile can include an identification of the user, contact information, other descriptive information regarding the user, and one or more user groups that the user is a member of Membership in a user group indicates that the user has the corresponding access rights to a corresponding application, based on the access rights and application that define the user group. A particular user can have the same (or similar) access rights across multiple applications, or different access rights in multiple applications. For example, the user may be designated as an administrator in one application, and a viewer (e.g., normal user) in another. The designated access rights for a user in multiple applications, as described in the user profile of the user stored in the IAM database, can be propagated to the various applications in the platform. In some implementations, any changes to user access rights that are specified through the access management interfaces of the individual applications can also be propagated back to the user profile in the IAM database. Accordingly, changes to the user profile for a user can be specified through the unified IAM interface of the IAM tool as well as through the individual access rights management interfaces of the individual applications in the platform. Implementations provide the unified IAM tool which may allow an operator to avoid using the individual access rights management interfaces of the individual applications, thus creating a more efficient workflow compared to previously available solutions.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Jadhav et al. into the combination of Kirti et al. and WADHWA et al. in order to managing user identity and access privileges across multiple applications (See Jadhav et al. ¶ [0003]).
As to claim 9, the combination of Kirti et al. and WADHWA et al. teaches the method according to claim 1 above. However, it does not expressly teach the details of wherein the one or more signals are received based at least in part on an input to the first application for the sign-in having a same username as the first user profile of the organization.
Jadhav et al., from analogous art, teaches wherein the one or more signals are received based at least in part on an input to the first application for the sign-in having a same username as the first user profile of the organization (See ¶¶ [0041], [0030] Teaches that FIG. 2 depicts an example user profile 114, according to implementations of the present disclosure. As shown in this example, a user profile 114 can include a user ID 202, such as a unique ID for a particular user 120, and other user information 204 describing the user 120, such as user contact information (e.g., email address, phone number, etc.). The user profile 114 for a user 120 can also include user group information 206 that describes one or more user groups 208 in which the user 120 has been designated as a member. As described above, each user group 208 can be associated with a particular application 104 and a particular set of access rights on that application 104. User groups can be defined as being in a directory under an OU that corresponds to the application, as described above. The user profile 114 can be stored in a comma-separated values (CSV) format, or in some other suitable format. FIG. 1B illustrates the way in which implementations can facilitate migration of user profiles between platform environments 102, through the IAM tool and its use of a unified user profile that specified user access rights for multiple applications.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Jadhav et al. into the combination of Kirti et al. and WADHWA et al. in order to managing user identity and access privileges across multiple applications (See Jadhav et al. ¶ [0003]).
As to claim 13, the combination of Kirti et al. and WADHWA et al. teaches the system according to claim 12 above. However, it does not expressly teach the details of wherein, to perform the application management operation, the one or more processors are individually or collectively operable to execute the code to cause the identity management system to: configure, by the administrator of the organization via the identity management system, the at least one application to have authorized access, wherein the first plurality of applications comprises the at least one application based at least in part on configuring the at least one application to have authorized access.
Jadhav et al., from analogous art, teaches wherein, to perform the application management operation, the one or more processors are individually or collectively operable to execute the code to cause the identity management system to: configure, by the administrator of the organization via the identity management system, the at least one application to have authorized access, wherein the first plurality of applications comprises the at least one application based at least in part on configuring the at least one application to have authorized access (See ¶¶ [0021]-[0023], Teaches that the IAM tool employs a unified IAM database, such as a version of Active Directory, that stores a user profile for one or more users. The user profile can specify the access rights for the user in one or more of the various applications on the platform, including whether or not the user is authorized to access an application and, if so, the access rights (e.g., privileges) of the user in that application. For example, access rights can include whether the user has viewer privileges (e.g., as a normal, non-administrative user) or administrative privileges. The IAM database can provide for the centralized management of users and/or user groups across multiple applications. In some implementations, an organizational unit (OU) can be specified in the database for each application. The OU can include any appropriate number of users groups, which each define a particular set of access rights for the particular application. If a user is a member of a user group, that can indicate that the user has the corresponding access rights to the corresponding application as specified by the user group. The IAM tool can connect to the IAM database and access the various defined OUs in the database. Based on the access rights defined by the user groups in the OUs, and based on the users who are designated (e.g., in their user profiles) as members of various user group(s), the IAM tool can propagate the access rights for each user to the appropriate applications in the platform. In this way, the IAM tool can provide centralized user identity and access rights management for all the applications in the platform. In some implementations, a user profile can be a record stored in the unified IAM database. The user profile can include an identification of the user, contact information, other descriptive information regarding the user, and one or more user groups that the user is a member of Membership in a user group indicates that the user has the corresponding access rights to a corresponding application, based on the access rights and application that define the user group. A particular user can have the same (or similar) access rights across multiple applications, or different access rights in multiple applications. For example, the user may be designated as an administrator in one application, and a viewer (e.g., normal user) in another. The designated access rights for a user in multiple applications, as described in the user profile of the user stored in the IAM database, can be propagated to the various applications in the platform. In some implementations, any changes to user access rights that are specified through the access management interfaces of the individual applications can also be propagated back to the user profile in the IAM database. Accordingly, changes to the user profile for a user can be specified through the unified IAM interface of the IAM tool as well as through the individual access rights management interfaces of the individual applications in the platform. Implementations provide the unified IAM tool which may allow an operator to avoid using the individual access rights management interfaces of the individual applications, thus creating a more efficient workflow compared to previously available solutions.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Jadhav et al. into the combination of Kirti et al. and WADHWA et al. in order to managing user identity and access privileges across multiple applications (See Jadhav et al. ¶ [0003]).
Claims 8, 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kirti et al. (US 20170251013 A1) and WADHWA et al. (US 20240176855 A1) and further in view of Caldwell (US 20200007555 A1).
As to claim 8, the combination of Kirti et al. and WADHWA et al. teaches the method according to claim 1 above. However, it does not expressly teach the details of wherein the one or more signals are received via a browser extension installed in a browser of a first user device associated with the first user profile of the organization.
Caldwell, from analogous art, teaches wherein the one or more signals are received via a browser extension installed in a browser of a first user device associated with the first user profile of the organization (See ¶¶ [0041]-[0044], Teaches that the browser 700 can implement a browser extension 701. The browser extension 701 can perform functions (e.g., monitoring web activity, extracting web page content from the web browser, exposing an Application Programming Interface (API) to query Document Object Model (DOM) elements, reporting events (e.g., click and update) triggered on specific elements, and set cookies against a specified Uniform Resource Locator (URL)). In this example, the browser extension 701 implements entities 702 and 703, which can extract content from web pages viewed using the web browser and monitor web activity by the user respectively. The assessment entity 601 may signal to the web browser 700 to send content from one or more web pages visited using the web browser to the assessment entity. The assessment entity may indicate to the web browser content and/or events of interest from web pages visited using the web browser that are to be reported to the assessment entity. Browser events (for example, websites visited, redirects, uploaded files, downloaded files, text copied into input fields, etc.) can also be fed from the browser extension 701 back into the agent along the communication channel 800, and into the assessment entity 601 at the agent 600. In this example, the scripting engine at the agent can control the browser extension's functionality and/or correlate reported information to detect a successful user authentication and track subsequent activity at the web browser, as will be described in more detail below. The scripting engine can also configure the browser extension 701 to report when Document Object Model (DOM) elements with specific attributes are added or interacted with.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Caldwell into the combination of Kirti et al. and WADHWA et al. in order to implement meaningful data loss protection controls (See Caldwell ¶ [0007]).
As to claim 19, the combination of Kirti et al. and WADHWA et al. teaches the system according to claim 12 above. However, it does not expressly teach the details of wherein the one or more signals are received via a browser extension installed in a browser of a first user device associated with the first user profile of the organization.
Caldwell, from analogous art, teaches wherein the one or more signals are received via a browser extension installed in a browser of a first user device associated with the first user profile of the organization (See ¶¶ [0041]-[0044], Teaches that the browser 700 can implement a browser extension 701. The browser extension 701 can perform functions (e.g., monitoring web activity, extracting web page content from the web browser, exposing an Application Programming Interface (API) to query Document Object Model (DOM) elements, reporting events (e.g., click and update) triggered on specific elements, and set cookies against a specified Uniform Resource Locator (URL)). In this example, the browser extension 701 implements entities 702 and 703, which can extract content from web pages viewed using the web browser and monitor web activity by the user respectively. The assessment entity 601 may signal to the web browser 700 to send content from one or more web pages visited using the web browser to the assessment entity. The assessment entity may indicate to the web browser content and/or events of interest from web pages visited using the web browser that are to be reported to the assessment entity. Browser events (for example, websites visited, redirects, uploaded files, downloaded files, text copied into input fields, etc.) can also be fed from the browser extension 701 back into the agent along the communication channel 800, and into the assessment entity 601 at the agent 600. In this example, the scripting engine at the agent can control the browser extension's functionality and/or correlate reported information to detect a successful user authentication and track subsequent activity at the web browser, as will be described in more detail below. The scripting engine can also configure the browser extension 701 to report when Document Object Model (DOM) elements with specific attributes are added or interacted with.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Caldwell into the combination of Kirti et al. and WADHWA et al. in order to implement meaningful data loss protection controls (See Caldwell ¶ [0007]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to James R Hollister whose telephone number is (571)270-3152. The examiner can normally be reached Mon - Fri 7:30 am - 4:00 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, Philip Chea can be reached at (571) 272-3951. 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.
James Hollister
/J.R.H./Examiner, Art Unit 2499 9/10/26
/PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights