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.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim 1-20 rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more.
Claim 1, 12, 20 rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more. The claim(s) recite(s) “receiving one or more signals associated with a sign-in to a first application via 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; generating 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; and performing 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 generating the report.”
The limitation of “generating 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” as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind (mental process). That is, nothing in the claim element precludes the step from practically being performed in the mind. For example, “generating a report” in the context of this claim encompasses the user manually looking at the logs and making notes of the data. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because the technical improvement is the improved security related to application access by users of an organization in ¶ [0086] of the spec. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because: “receiving one or more signals associated with a sign-in to a first application via 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” and “performing 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 generating the report” are insignificant extra-solution activity to the judicial exception. The claims are not patent eligible.
Claims 2-11, 13-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to abstract idea without significantly more. These claims are all directed towards an abstract idea (mental process) and/or insignificant extra-solution activity to the judicial exception. The claims are not patent eligible.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
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. 102(a)(2) as being anticipated by Kirti et al. (US 20170251013 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 via 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.);
generating 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], 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.);
and performing 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 generating the report (See ¶¶ [0184]-[0190], 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).).
As to claim 3, Kirti 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, Kirti 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, Kirti 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, Kirti 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, Kirti 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, Kirti 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, Kirti 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 via 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.);
generate 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], 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.);
and perform 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 generating the report (See ¶¶ [0184]-[0190], 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).).
As to claim 14, Kirti 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, Kirti 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, Kirti 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, Kirti 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, Kirti 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 via 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.);
generate 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], 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.);
and perform 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 generating the report (See ¶¶ [0184]-[0190], 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).).
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 2, 9, 13 are rejected under 35 U.S.C. 103 as being unpatentable over Kirti et al. (US 20170251013 A1) and further in view of Jadhav et al. (US 20200007555 A1).
As to claim 2, Kirti 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 Kirti et al. in order to managing user identity and access privileges across multiple applications (See Jadhav et al. ¶ [0003]).
As to claim 9, Kirti 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 Kirti et al. in order to managing user identity and access privileges across multiple applications (See Jadhav et al. ¶ [0003]).
As to claim 13, Kirti 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 Kirti 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 further in view of Caldwell (US 20200007555 A1).
As to claim 8, Kirti 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 Kirti et al. in order to implement meaningful data loss protection controls (See Caldwell ¶ [0007]).
As to claim 19, Kirti 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 Kirti et al. in order to implement meaningful data loss protection controls (See Caldwell ¶ [0007]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
LEON PLATA et al. (US 20250055845 A1) teaches According to examples, an apparatus may include a processor and a memory on which is stored machine-readable instructions that when executed by the processor, may cause the processor to identify configuration information to be used by an on-premise access management service to provide authentication services to applications by users. The processor may also transform the identified configuration information into a transformed set of configuration information to be used by a cloud-based access management service to provide authentication services to the applications by users. In addition, the processor may store the transformed set of configuration information for use by the cloud-based access management service to provide authentication services to the applications by users to migrate authentication of the users from the on-premise access management service to the cloud-based access management service.
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 3/20/26
/PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499