DETAILED ACTION
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 . In communications filed on 02/05/2026. Claims 1-3, 5, 11-13, 15, and 20 are amended. Claims 4, 10, and 14 are cancelled. Claims 1-3, 5-9, 11-13, and 15-22 are pending in this examination.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. This examination is in response to US Patent Application No. 17/214,185.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission has been entered.
Response to Argument
Applicant's arguments filed 02/05/2026 have been fully considered but they are not persuasive:
Applicant submits on pages 10-11 of remarks filed on 09/17/2025 that the Advisory Action has not shown any features of Sarin that teach or suggest a "third-party file access control service detecting generation of one or more audit events," nor that teach or suggest "receiving, based at least in part on a report request being associated with an account that matches one or more settings in a system access control list, a report that includes an event log." Applicant respectfully requests reconsideration.
Examiner respectfully disagrees with applicant argument for claim 1 filed on 02/05/2026 on pages 10-11 of remarks.
While Manmohan discloses [¶38, The hypervisor security driver 202 may be implemented as a process operating on the VMM 112 and may be configured to communicating with a plurality of guest virtual machines 102, although only one is depicted here in FIG. 2 for clarity. The DLP manager 104, in one embodiment, communicates with each guest DLP component 108 via the DLP system 201. The DLP manager 104 is configured to receive notifications from the DLP component 108 that are indicative of virtual machine and file system activity events. Examples of virtual machine events include, but are not limited to, VM power on events, shutdown events, migration and reconfiguration events. Examples of file system events include, but are not limited to, file open events, file create events, file close (e.g., save) events, file read/write, copy/paste events, move file events and file deletion events], and [¶48, The DLP manager 104 in SVM identifies the user using a non-approved application or device. If there are no application or device control policies, the DLP manager 104 may apply DLP policy and response rule by identifying whether the file being accessed by the application contains sensitive information. The application accessing the sensitive data may or may not be approved. When a user in GVM accesses any file, the DLP manager 104 in the SVM intercepts the file open or create event. The DLP manager 104 retrieves the saved identity of the VM to determine the source GVM( equated to matching one or more settings). The DLP manager 104 uses the DLP kernel driver to identify the process or application, device being used, user and the file being access in the GVM. If the application or the device has source control policies access to the device and/or execution of application is blocked. If there are no application or device control policies, the DLP manager 104 applies DLP policy for monitoring file access activity, where the DLP manager 104 in SVM remotely reads the file data and performs detection on this local data. If the data violates a DLP policy, the DLP manager 104 in SVM remotely executes response rules in the GVM. The response rules can be, but not limited to, blocking access to the sensitive data], and [¶40].
Furthermore, Sarin discloses [ Col.6 lines 40-67, In one embodiment, the DLP agent 120 is further configured to detect when an application 140 (see FIG. 1) opens or requests to open a file from the network share 170. The DPL agent also is configured to notify a disk monitor 214 to enable disk monitoring of the local data store 130 for the identified application. The disk monitor 214 monitors the application for all file system events that might involve the data from the network share 170. File system events include, but are not limited to new file creations, writes of data to a local file (e.g., copying or pasting data from a remote file into a local file), and saving a file to a local data store 130. When disk monitoring is enabled, the disk monitor 214, together with the detection system 206(equated to third-party file access control service), identify DLP policy violations as described above. The disk monitor 214 detects the local file system event (e.g., opening, writing to, or closing a file stored on the local data store 130(equated to event logs)) and notifies the detection system 206. The detection system 206 analyzes data associated with the file system event and verifies that the movement of the data does not violate a DLP policy. In one embodiment, the disk monitor 214 is configured to monitor write operations of the identified application. In other words, the disk monitor 214, to improve efficiency, monitors save and file close operations instead of constantly monitoring every operation requested by the application. The DLP agent 120 instructs the disk monitor 214 to cease disk monitoring of the application 140 when the application 140 closes the file on the network share 170, or when the application 140 terminates], and [Col. 8 lines 1-12, At block 304, the processing logic instructs the disk monitor 214 to enable or begin to monitor the local data store 1300 (equated to even logs). The processing logic, at block 306, identifies file system events on the local data store 130 that correspond to the application 140). For example, each application 140 may be identified by an application ID or process number. The processing logic may be configured to monitor and identify file system events on the local data store that are associated with the application ID or process number. At block 308, the processing logic determines if the newly created or modified file associated with the identified file system event violates a DLP policy], and [Abstract].
Applicant submits on pages 11-12 of remarks filed on 09/17/2025 that the Advisory Action appears to allege that Narayanaswamy is relevant to "receiving, based at least in part on a report request being associated with an account that matches one or more settings in a system access control list, a report that includes an event log from the third-party file access control service," as recited in amended independent claim 1.
Examiner respectfully disagrees with applicant argument for claim 1 filed on 02/05/2026 on pages 11-12 of remarks.
While Manmohan discloses [¶38, The hypervisor security driver 202 may be implemented as a process operating on the VMM 112 and may be configured to communicating with a plurality of guest virtual machines 102, although only one is depicted here in FIG. 2 for clarity. The DLP manager 104, in one embodiment, communicates with each guest DLP component 108 via the DLP system 201. The DLP manager 104 is configured to receive notifications from the DLP component 108 that are indicative of virtual machine and file system activity events. Examples of virtual machine events include, but are not limited to, VM power on events, shutdown events, migration and reconfiguration events. Examples of file system events include, but are not limited to, file open events, file create events, file close (e.g., save) events, file read/write, copy/paste events, move file events and file deletion events], and [¶48, The DLP manager 104 in SVM identifies the user using a non-approved application or device. If there are no application or device control policies, the DLP manager 104 may apply DLP policy and response rule by identifying whether the file being accessed by the application contains sensitive information. The application accessing the sensitive data may or may not be approved. When a user in GVM accesses any file, the DLP manager 104 in the SVM intercepts the file open or create event. The DLP manager 104 retrieves the saved identity of the VM to determine the source GVM( equated to matching one or more settings). The DLP manager 104 uses the DLP kernel driver to identify the process or application, device being used, user and the file being access in the GVM. If the application or the device has source control policies access to the device and/or execution of application is blocked. If there are no application or device control policies, the DLP manager 104 applies DLP policy for monitoring file access activity, where the DLP manager 104 in SVM remotely reads the file data and performs detection on this local data. If the data violates a DLP policy, the DLP manager 104 in SVM remotely executes response rules in the GVM. The response rules can be, but not limited to, blocking access to the sensitive data], and [¶40].
Furthermore, Sarin discloses [ Col.6 lines 40-67, In one embodiment, the DLP agent 120 is further configured to detect when an application 140 (see FIG. 1) opens or requests to open a file from the network share 170. The DPL agent also is configured to notify a disk monitor 214 to enable disk monitoring of the local data store 130 for the identified application. The disk monitor 214 monitors the application for all file system events that might involve the data from the network share 170. File system events include, but are not limited to new file creations, writes of data to a local file (e.g., copying or pasting data from a remote file into a local file), and saving a file to a local data store 130. When disk monitoring is enabled, the disk monitor 214, together with the detection system 206(equated to third-party file access control service), identify DLP policy violations as described above. The disk monitor 214 detects the local file system event (e.g., opening, writing to, or closing a file stored on the local data store 130(equated to event logs)) and notifies the detection system 206. The detection system 206 analyzes data associated with the file system event and verifies that the movement of the data does not violate a DLP policy. In one embodiment, the disk monitor 214 is configured to monitor write operations of the identified application. In other words, the disk monitor 214, to improve efficiency, monitors save and file close operations instead of constantly monitoring every operation requested by the application. The DLP agent 120 instructs the disk monitor 214 to cease disk monitoring of the application 140 when the application 140 closes the file on the network share 170, or when the application 140 terminates], and [Col. 8 lines 1-12, At block 304, the processing logic instructs the disk monitor 214 to enable or begin to monitor the local data store 1300 (equated to even logs). The processing logic, at block 306, identifies file system events on the local data store 130 that correspond to the application 140). For example, each application 140 may be identified by an application ID or process number. The processing logic may be configured to monitor and identify file system events on the local data store that are associated with the application ID or process number. At block 308, the processing logic determines if the newly created or modified file associated with the identified file system event violates a DLP policy], and [Abstract].
Examiner Note: Examiner encourages applicant to review Narayanaswamy et al. (US 2017/0264640 A1) which is used in mapping claim 9 also discloses [ 189-190, FIG.1C, event logs from external sources can be provided to a security system event log entries including fields such as user identity, timestamp, and activity data...)
Applicant submits on pages 12-15 of remarks filed on 09/17/2025 that Manmohan, Sarin, Kraus, Carlson, and Narayanaswamy-alone or in any combination-do not teach or suggest all of the features of amended independent claims 1, 11, and 20.
receiving, based at least in part on a report request being associated with an account that matches one or more settings in a system access control list, a report that includes an event log from the third-party file access control service, the receiving based at least in part on the third-party file access control service detecting generation of one or more audit events by an operating system of the computing environment, and the event log comprising an identity of a first user who has accessed the first file, activity data indicating a change of the first file, and a timestamp associated with the change of the first file… causing, in a user interface of a client device, display of a first notification including an indication of the identity of the first user and a first indication of the potential violation of the second policy based on the change of the first file. Independent claims 11 and 20 have been amended to include similar features.
Examiner respectfully disagrees with applicant argument for claims 1, 11, and 20 filed on 02/05/2026 on pages 12-15 of remarks
While Manmohan discloses [¶38, The hypervisor security driver 202 may be implemented as a process operating on the VMM 112 and may be configured to communicating with a plurality of guest virtual machines 102, although only one is depicted here in FIG. 2 for clarity. The DLP manager 104, in one embodiment, communicates with each guest DLP component 108 via the DLP system 201. The DLP manager 104 is configured to receive notifications from the DLP component 108 that are indicative of virtual machine and file system activity events. Examples of virtual machine events include, but are not limited to, VM power on events, shutdown events, migration and reconfiguration events. Examples of file system events include, but are not limited to, file open events, file create events, file close (e.g., save) events, file read/write, copy/paste events, move file events and file deletion events], and [¶48, The DLP manager 104 in SVM identifies the user using a non-approved application or device. If there are no application or device control policies, the DLP manager 104 may apply DLP policy and response rule by identifying whether the file being accessed by the application contains sensitive information. The application accessing the sensitive data may or may not be approved. When a user in GVM accesses any file( equated to user identity), the DLP manager 104 in the SVM intercepts the file open or create event. The DLP manager 104 retrieves the saved identity of the VM to determine the source GVM( equated to matching one or more settings). The DLP manager 104 uses the DLP kernel driver to identify the process or application, device being used, user and the file being access in the GVM. If the application or the device has source control policies access to the device and/or execution of application is blocked. If there are no application or device control policies, the DLP manager 104 applies DLP policy for monitoring file access activity, where the DLP manager 104 in SVM remotely reads the file data and performs detection on this local data. If the data violates a DLP policy, the DLP manager 104 in SVM remotely executes response rules in the GVM. The response rules can be, but not limited to, blocking access to the sensitive data], and [¶40].
Furthermore, Sarin discloses [ Col.6 lines 40-67, In one embodiment, the DLP agent 120 is further configured to detect when an application 140 (see FIG. 1) opens or requests to open a file from the network share 170. The DPL agent also is configured to notify a disk monitor 214 to enable disk monitoring of the local data store 130 for the identified application. The disk monitor 214 monitors the application for all file system events that might involve the data from the network share 170. File system events include, but are not limited to new file creations, writes of data to a local file (e.g., copying or pasting data from a remote file into a local file), and saving a file to a local data store 130. When disk monitoring is enabled, the disk monitor 214, together with the detection system 206(equated to third-party file access control service), identify DLP policy violations as described above. The disk monitor 214 detects the local file system event (e.g., opening, writing to, or closing a file stored on the local data store 130(equated to event logs)) and notifies the detection system 206. The detection system 206 analyzes data associated with the file system event and verifies that the movement of the data does not violate a DLP policy. In one embodiment, the disk monitor 214 is configured to monitor write operations of the identified application. In other words, the disk monitor 214, to improve efficiency, monitors save and file close operations instead of constantly monitoring every operation requested by the application. The DLP agent 120 instructs the disk monitor 214 to cease disk monitoring of the application 140 when the application 140 closes the file on the network share 170, or when the application 140 terminates], and [Col. 8 lines 1-12, At block 304, the processing logic instructs the disk monitor 214 to enable or begin to monitor the local data store 1300 (equated to even logs). The processing logic, at block 306, identifies file system events on the local data store 130 that correspond to the application 140). For example, each application 140 may be identified by an application ID or process number. The processing logic may be configured to monitor and identify file system events on the local data store that are associated with the application ID or process number. At block 308, the processing logic determines if the newly created or modified file associated with the identified file system event violates a DLP policy], and [Abstract].
Examiner Note: Examiner encourages applicant to review Narayanaswamy et al. (US 2017/0264640 A1) which is used in mapping claim 9 also discloses [ 189-190, FIG.1C, event logs from external sources can be provided to a security system event log entries including fields such as user identity, timestamp, and activity data...)
Examiner maintains the 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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
Claims 1-3, 5-8, 11-13, 15-18 and 20-22 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US 2014/0237537 A1) issued to Manmohan and in view of US Patent No. (US8,832,780) issued to Sarin and further in view of Carlson et al. (US 2009/0055889 A1), hereafter Carlson , and further in view of US Patent No. (US US2020/0380160) issued to Kraus .
Regarding claims 1, 11, and 20 Manmohan discloses a method comprising identifying a list of files for which to receive event logs generated by a third- party file access control service, wherein the files are in a computing environment, and wherein the list of files comprises a first file [¶38, The hypervisor security driver 202 may be implemented as a process operating on the VMM 112 and may be configured to communicating with a plurality of guest virtual machines 102, although only one is depicted here in FIG. 2 for clarity. The DLP manager 104(equated to third- party file access control service), in one embodiment, communicates with each guest DLP component 108 via the DLP system 201. The DLP manager 104 is configured to receive notifications from the DLP component 108 that are indicative of virtual machine and file system activity events. Examples of virtual machine events include, but are not limited to, VM power on events, shutdown events, migration and reconfiguration events. Examples of file system events include, but are not limited to, file open events, file create events, file close (e.g., save) events, file read/write, copy/paste events, move file events and file deletion events], and [¶48, The DLP manager 104 in SVM identifies the user using a non-approved application or device. If there are no application or device control policies, the DLP manager 104 may apply DLP policy and response rule by identifying whether the file being accessed by the application contains sensitive information. The application accessing the sensitive data may or may not be approved. When a user in GVM accesses any file, the DLP manager 104 in the SVM intercepts the file open or create event. The DLP manager 104 retrieves the saved identity of the VM to determine the source GVM. The DLP manager 104 uses the DLP kernel driver to identify the process or application, device being used, user and the file being access in the GVM. If the application or the device has source control policies access to the device and/or execution of application is blocked. If there are no application or device control policies, the DLP manager 104 applies DLP policy for monitoring file access activity, where the DLP manager 104 in SVM remotely reads the file data and performs detection on this local data. If the data violates a DLP policy, the DLP manager 104 in SVM remotely executes response rules in the GVM. The response rules can be, but not limited to, blocking access to the sensitive data], and [¶40]; and
and causing, in a user interface of a client device, display of a first notification including an indication of the identity of the first user and a first indication of the potential violation of the second policy based on the change of the first file
Manmohan discloses [¶¶5,59, user notification may be presented by DLP user interface; in response to a policy violation, processing logic instructs the DLP user interface to indicate to the user that the user has violated a DLP policy).
receiving, based at least in part on a report request being associated with an account that matches one or more settings in a system access control list, a report that includes an event log from the third-party file access control service, the receiving based at least in part on the third-party file access control service detecting generation of one or more audit events by an operating system of the computing environment
While Manmohan discloses [¶38, The hypervisor security driver 202 may be implemented as a process operating on the VMM 112 and may be configured to communicating with a plurality of guest virtual machines 102, although only one is depicted here in FIG. 2 for clarity. The DLP manager 104, in one embodiment, communicates with each guest DLP component 108 via the DLP system 201. The DLP manager 104 is configured to receive notifications from the DLP component 108 that are indicative of virtual machine and file system activity events. Examples of virtual machine events include, but are not limited to, VM power on events, shutdown events, migration and reconfiguration events. Examples of file system events include, but are not limited to, file open events, file create events, file close (e.g., save) events, file read/write, copy/paste events, move file events and file deletion events], and [¶48, The DLP manager 104 in SVM identifies the user using a non-approved application or device. If there are no application or device control policies, the DLP manager 104 may apply DLP policy and response rule by identifying whether the file being accessed by the application contains sensitive information. The application accessing the sensitive data may or may not be approved. When a user in GVM accesses any file, the DLP manager 104 in the SVM intercepts the file open or create event. The DLP manager 104 retrieves the saved identity of the VM to determine the source GVM( equated to matching one or more settings). The DLP manager 104 uses the DLP kernel driver to identify the process or application, device being used, user and the file being access in the GVM. If the application or the device has source control policies access to the device and/or execution of application is blocked. If there are no application or device control policies, the DLP manager 104 applies DLP policy for monitoring file access activity, where the DLP manager 104 in SVM remotely reads the file data and performs detection on this local data. If the data violates a DLP policy, the DLP manager 104 in SVM remotely executes response rules in the GVM. The response rules can be, but not limited to, blocking access to the sensitive data], and [¶40].
Furthermore, Sarin discloses [ Col.6 lines 40-67, In one embodiment, the DLP agent 120 is further configured to detect when an application 140 (see FIG. 1) opens or requests to open a file from the network share 170. The DPL agent also is configured to notify a disk monitor 214 to enable disk monitoring of the local data store 130 for the identified application. The disk monitor 214 monitors the application for all file system events that might involve the data from the network share 170. File system events include, but are not limited to new file creations, writes of data to a local file (e.g., copying or pasting data from a remote file into a local file), and saving a file to a local data store 130. When disk monitoring is enabled, the disk monitor 214, together with the detection system 206(equated to third-party file access control service), identify DLP policy violations as described above. The disk monitor 214 detects the local file system event (e.g., opening, writing to, or closing a file stored on the local data store 130(equated to event logs)) and notifies the detection system 206. The detection system 206 analyzes data associated with the file system event and verifies that the movement of the data does not violate a DLP policy. In one embodiment, the disk monitor 214 is configured to monitor write operations of the identified application. In other words, the disk monitor 214, to improve efficiency, monitors save and file close operations instead of constantly monitoring every operation requested by the application. The DLP agent 120 instructs the disk monitor 214 to cease disk monitoring of the application 140 when the application 140 closes the file on the network share 170, or when the application 140 terminates], and [Col. 8 lines 1-12, At block 304, the processing logic instructs the disk monitor 214 to enable or begin to monitor the local data store 1300 (equated to even logs). The processing logic, at block 306, identifies file system events on the local data store 130 that correspond to the application 140). For example, each application 140 may be identified by an application ID or process number. The processing logic may be configured to monitor and identify file system events on the local data store that are associated with the application ID or process number. At block 308, the processing logic determines if the newly created or modified file associated with the identified file system event violates a DLP policy], and [Abstract].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Manmohan by incorporating “enable disk monitoring of the local data store”, as taught by Sarin. One could have been motivated to do so in order to detect when an application (see FIG. 1) opens or requests to open a file from the network share, where the disk monitor monitors the application for all file system events that might involve the data from the network share to identify DLP policy violations [Sarin, Abstract, Col.6 lines 40-67; [Col. 8 lines 1-12]].
and the event log comprising an identity of a first user who has accessed the first file, activity data indicating a change of the first file, and a timestamp associated with the change of the first file
While Manmohan discloses [¶38, The hypervisor security driver 202 may be implemented as a process operating on the VMM 112 and may be configured to communicating with a plurality of guest virtual machines 102, although only one is depicted here in FIG. 2 for clarity. The DLP manager 104, in one embodiment, communicates with each guest DLP component 108 via the DLP system 201. The DLP manager 104 is configured to receive notifications from the DLP component 108 that are indicative of virtual machine and file system activity events. Examples of virtual machine events include, but are not limited to, VM power on events, shutdown events, migration and reconfiguration events. Examples of file system events include, but are not limited to, file open events, file create events, file close (e.g., save) events, file read/write, copy/paste events, move file events and file deletion events], and [¶48, The DLP manager 104 in SVM identifies the user using a non-approved application or device. If there are no application or device control policies, the DLP manager 104 may apply DLP policy and response rule by identifying whether the file being accessed by the application contains sensitive information. The application accessing the sensitive data may or may not be approved. When a user in GVM accesses any file, the DLP manager 104 in the SVM intercepts the file open or create event. The DLP manager 104 retrieves the saved identity of the VM to determine the source GVM( equated to matching one or more settings). The DLP manager 104 uses the DLP kernel driver to identify the process or application, device being used, user and the file being access in the GVM. If the application or the device has source control policies access to the device and/or execution of application is blocked. If there are no application or device control policies, the DLP manager 104 applies DLP policy for monitoring file access activity, where the DLP manager 104 in SVM remotely reads the file data and performs detection on this local data. If the data violates a DLP policy, the DLP manager 104 in SVM remotely executes response rules in the GVM. The response rules can be, but not limited to, blocking access to the sensitive data], and [¶40].
Furthermore, Carlson discloses [ ¶20, the system may allow the sensitive data to be written to memory. In the latter case, the system may store information (such as memory address information or time-stamp information) regarding the writing of the sensitive data so that the system may be able to quickly search the relevant space of the memory to confirm that the sensitive data has been erased according to some configured policy regarding allowed retention time].
Carlson is considered to be analogous to the claimed invention because it concerns a system for detecting the writing of sensitive or prohibited information via scanning for sensitive of prohibited content. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing data of the claimed invention to have modified the method of Manmohan, and Sarin, to include the capability to update analyzer and policy data based on user selection and changes in regulation. One could have been motivated to do so in order to enable an institution utilizing such a method to better comply with information security policies ([Carlson ¶9] invention better enables a financial institution to comply with information security policies).
deploying, in response to the event log indicating the change of the first file, a plurality of analyzers, the plurality of analyzers including a first analyzer and a second analyzer different from the first analyzer, wherein the change of the first file comprises an edit or creation of the first file; scanning content of the first file based at least in part on deploying the plurality of analyzers to identify a first sensitive data item in accordance with a data classification procedure; matching the first analyzer with the first sensitive data item in the first file; scanning the content of the first file based at least in part on deploying the plurality of analyzers to identify a second sensitive data item in accordance with the data classification procedure, wherein the second sensitive data item is different from the first sensitive data item; matching the second analyzer with the second sensitive data item in the first file
while Manmohan discloses this limitation as: [ ¶38, Examples of file system events include, but are not limited to, file open events, file create events, file close (e.g., save) events, file read/write, copy/paste events, move file events and file deletion events], and [¶40]; and [¶¶42,46, DLP polices 308 specify rules for monitoring content to detect confidential information, such as specifying keywords; DLP manager 104 analyzes data associated with a file change and identifies policy violations in accordance with polices 308], and [¶56, a method 500 for monitoring file system events; processing logic receives a notification from a DLP component 108 that indicates a user is closing or saving a file), and [ ¶58, At block 514, the processing logic determines if the analyzed data violates the DLP policy 308. For example, the DLP policy 308 rule may specify one or more keywords (e.g., "confidential," "sensitive," "stock," names of specific diseases (e.g., "cancer," "HIV," etc.), etc.) for searching various files, messages and the like. In addition to keywords, the DLP policy 308 may include other rules for detecting presence of confidential data in information content being monitored. For example, in a financial organization, a DLP policy 308 may specify that if a message contains the word "confidential," further search of the message should be performed to determine whether the message includes customer data (e.g., a social security number, first name, last name, etc.) or other sensitive information (e.g., financial reports, source code, etc.)], and ¶63, …. , the processing logic is configured to analyze the content for words and media objects (e.g., images, audio objects and video objects) that violate the DLP policy. If the processing logic determines the analyzed data does not violate the DLP policy 308, the processing logic allows the data transfer at block 610. If the analyzed data violate the DLP policy, the processing logic at block 618 executes the response rule(s) 310 associated with the DLP policy 308 and restores the copy of the file to its original location].
Furthermore, Kraus discloses:
[¶240, Some embodiments automatically choose which scanners 430 to use, based on some criteria, e.g., the data types found so far, a data container's characteristics, statistics gathered, iteration number, scanner's activation cost, or a combination thereof. In some embodiments, multiple data scanners 430 are configured to perform scanning for sensitive data 212 which meets a respective predefined sensitivity criterion 402 implemented in the scanner. The processor 110 is configured to set the scanning-condition 504 to enable zero or more scanners 430 for a particular iteration 414 based on at least one of the following: which sensitivity type 404 or combination of sensitivity types have been found by previous scanning, metadata 432 of the group 420 of stored items, the data security classification statistical measure 422, an iteration number 602 which indicates how many iterations 414 of the data sampling sequence have been performed, or a computational cost 510 that is associated with a particular scanner], and [see FIG 4 and corresponding text for more detail].
identifying a potential violation of a second policy from a plurality of policies based on matching both of the first sensitive data item and the second sensitive data item to a first predetermined set of analyzers that includes the first analyzer and the second analyzer
while Manmohan discloses this limitation as: [¶¶42,46, DLP polices 308 specify rules for monitoring content to detect confidential information, such as specifying keywords; DLP manager 104 analyzes data associated with a file change and identifies policy violations in accordance with polices 308], and [¶56, a method 500 for monitoring file system events; processing logic receives a notification from a DLP component 108 that indicates a user is closing or saving a file), and [ ¶58, At block 514, the processing logic determines if the analyzed data violates the DLP policy 308. For example, the DLP policy 308 rule may specify one or more keywords (e.g., "confidential," "sensitive," "stock," names of specific diseases (e.g., "cancer," "HIV," etc.), etc.) for searching various files, messages and the like. In addition to keywords, the DLP policy 308 may include other rules for detecting presence of confidential data in information content being monitored. For example, in a financial organization, a DLP policy 308 may specify that if a message contains the word "confidential," further search of the message should be performed to determine whether the message includes customer data (e.g., a social security number, first name, last name, etc.) or other sensitive information (e.g., financial reports, source code, etc.)], and ¶63, …. , the processing logic is configured to analyze the content for words and media objects (e.g., images, audio objects and video objects) that violate the DLP policy. If the processing logic determines the analyzed data does not violate the DLP policy 308, the processing logic allows the data transfer at block 610. If the analyzed data violate the DLP policy, the processing logic at block 618 executes the response rule(s) 310 associated with the DLP policy 308 and restores the copy of the file to its original location].
Furthermore, Kraus discloses:
[¶240, Some embodiments automatically choose which scanners 430 to use, based on some criteria, e.g., the data types found so far, a data container's characteristics, statistics gathered, iteration number, scanner's activation cost, or a combination thereof. In some embodiments, multiple data scanners 430 are configured to perform scanning for sensitive data 212 which meets a respective predefined sensitivity criterion 402 implemented in the scanner. The processor 110 is configured to set the scanning-condition 504 to enable zero or more scanners 430 for a particular iteration 414 based on at least one of the following: which sensitivity type 404 or combination of sensitivity types have been found by previous scanning, metadata 432 of the group 420 of stored items, the data security classification statistical measure 422, an iteration number 602 which indicates how many iterations 414 of the data sampling sequence have been performed, or a computational cost 510 that is associated with a particular scanner], and [see FIG 4 and corresponding text for more detail].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Manmohan, Sarin, and Carlson by incorporating “multiple data scanner”, as taught by Kraus. One could have been motivated to do so in order to perform operations that enhance cybersecurity and data categorization efficiency by providing reliable statistics about the number and location of sensitive data of different categories [ Kraus, ¶4].
Regarding claims 2, and 12, the first notification further includes respective indications of the identity data of the customer, the timestamp of the first event log, the activity data, or any combination thereof.
Manmohan discloses: [¶38... The DLP manager 104 is configured to receive notifications from the DLP component 108 that are indicative of ...file system activity events.... Examples of file system events include, but are not limited to, file open events, file create events, file close (e.g., save) events, file read/write, copy/paste events, move file events and file deletion events], and [¶45], and ¶48, The DLP manager 104 in SVM identifies the user using a non-approved application or device. If there are no application or device control policies, the DLP manager 104 may apply DLP policy and response rule by identifying whether the file being accessed by the application contains sensitive information. The application accessing the sensitive data may or may not be approved. When a user in GVM accesses any file, the DLP manager 104 in the SVM intercepts the file open or create event. The DLP manager 104 retrieves the saved identity of the VM to determine the source GVM. The DLP manager 104 uses the DLP kernel driver to identify the process or application, device being used, user and the file being access in the GVM. If the application or the device has source control policies access to the device and/or execution of application is blocked. If there are no application or device control policies, the DLP manager 104 applies DLP policy for monitoring file access activity, where the DLP manager 104 in SVM remotely reads the file data and performs detection on this local data. If the data violates a DLP policy, the DLP manager 104 in SVM remotely executes response rules in the GVM. The response rules can be, but not limited to, blocking access to the sensitive data.].
Furthermore, Sarin discloses:
[Col. 6 lines 20-27, ...The information sent to the DLP service provider may identify, for example, the DLP policy being violated, the type of data being transferred, the destination entity specified to receive the data transfer, or other information concerning the violation, an identifier of the user or the client computing system 102 that caused the violation, as well as other information that may be helpful in remedying or recording the incident].
Furthermore, Carlson discloses [ ¶20, the system may allow the sensitive data to be written to memory. In the latter case, the system may store information (such as memory address information or time-stamp information) regarding the writing of the sensitive data so that the system may be able to quickly search the relevant space of the memory to confirm that the sensitive data has been erased according to some configured policy regarding allowed retention time].
Regarding claims 3, and 13, Manmohan discloses wherein the first user is managed by a client associated with the client device [¶38... The DLP manager 104 is configured to receive notifications from the DLP component 108 that are indicative of ...file system activity events.... Examples of file system events include, but are not limited to, file open events, file create events, file close (e.g., save) events, file read/write, copy/paste events, move file events and file deletion events], and [¶45], and ¶48, The DLP manager 104 in SVM identifies the user using a non-approved application or device. If there are no application or device control policies, the DLP manager 104 may apply DLP policy and response rule by identifying whether the file being accessed by the application contains sensitive information. The application accessing the sensitive data may or may not be approved. When a user in GVM accesses any file, the DLP manager 104 in the SVM intercepts the file open or create event. The DLP manager 104 retrieves the saved identity of the VM to determine the source GVM. The DLP manager 104 uses the DLP kernel driver to identify the process or application, device being used, user and the file being access in the GVM. If the application or the device has source control policies access to the device and/or execution of application is blocked. If there are no application or device control policies, the DLP manager 104 applies DLP policy for monitoring file access activity, where the DLP manager 104 in SVM remotely reads the file data and performs detection on this local data. If the data violates a DLP policy, the DLP manager 104 in SVM remotely executes response rules in the GVM. The response rules can be, but not limited to, blocking access to the sensitive data.].
Regarding claims 5, and 15, Manmohan, and Kraus discloses the method of claim 1, wherein the plurality of analyzers is implemented in a computing environment of the first user associated with change of the first file
Manmohan discloses: [[¶42, DLP polices 308 specify rules for monitoring content to detect confidential information, such as specifying keywords; DLP manager 104 analyzes data associated with a file change and identifies policy violations in accordance with polices 308], and [¶56, a method 500 for monitoring file system events; processing logic receives a notification from a DLP component 108 that indicates a user is closing or saving a file], and[¶46, DLP component 108 of a particular VM associated with a policy violation may perform analyzing actions locally].
Kraus discloses: [¶240, In some embodiments, multiple data scanners 430 are configured to perform scanning for sensitive data 212 which meets a respective predefined sensitivity criterion 402 implemented in the scanner. The processor 110 is configured to set the scanning-condition 504 to enable zero or more scanners 430 for a particular iteration 414 based on at least one of the following: which sensitivity type 404 or combination of sensitivity types have been found by previous scanning, metadata 432 of the group 420 of stored items, the data security classification statistical measure 422, an iteration number 602 which indicates how many iterations 414 of the data sampling sequence have been performed, or a computational cost 510 that is associated with a particular scanner].
Regarding claims 6, and 16, Manmohan, Sarin, and Kraus do not explicitly disclose however, Carlson teaches periodically updating the plurality of policies based on a recent change of an industrial regulation [¶57, host processor 117 may query databases and websites of security organizations to determine if any changes have been made to existing security policies, or if new security policies have been created, updating or adding security policy data if this is the case).
Carlson is considered to be analogous to the claimed invention because it concerns a system for detecting the writing of sensitive or prohibited information via scanning for sensitive of prohibited content. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing data of the claimed invention to have modified the method of Manmohan, Sarin, and Kraus to include the capability to update analyzer and policy data based on user selection and changes in regulation. One could have been motivated to do so in order to enable an institution utilizing such a method to better comply with information security policies ([Carlson ¶9] invention better enables a financial institution to comply with information security policies).
Regarding claims 7, and 17, Manmohan discloses the method of claim 1, wherein each analyzer in the plurality of analyzers is generated for a specific type of sensitive data item that is customized to a particular customer [¶¶42,45, rules associated with DLP policies 308 may specify to determine the presence of customer data and other specified confidential information; said policies may be associated with a customized VM profile 306 for a specific user who logs on).
Regarding claims 8, and 18, Manmohan discloses the method of claim 1, further comprising:
matching a third analyzer with a third sensitive data item in the first file [¶¶42,46, DLP manager 104 identifies the content within a file that is associated with a policy violation that indicates the presence of confidential information); and
identifying a first policy that corresponds to a second pre-determined set of analyzers that includes the third analyzer [¶¶42,46, DLP manager 104 identifies relevant policy associated with a policy violation from policies 308 provided to DLP manager 104); and
and causing display of the first notification in the user interface of the client device to further include a second indication that the first policy may be violated based on the file change of the first file [¶¶50,59, user notification may be presented by DLP user interface; in response to a policy violation, processing logic instructs the DLP user interface to indicate to the user that the user has violated a DLP policy].
Regarding claim 21, further comprising: requesting the third-party file access control service to track a type of access of files of the list of files, wherein the event logs generated by the third-party file access control service indicate changes to the files of the list of files that are based at least in part on performance of the type of access associated with the request to track.
The combination of Manmohan and Sarin discloses:
Manmohan discloses [¶40, The DLP component 108 is configured to communicate with the DLP manager 104 file system events. For example, when a user initiates a file system event within the guest VM 102, the DLP component 108 intercepts the file system event and analyzes the event to determine the type of file system event (e.g., open, create, close, move, copy, read, write, delete, etc.) and transmits this information to the DLP manager 104. The information collected by the DLP component 108 and communicated with the DLP manager 104 may also comprise file or object information including, but not limited to, source, destination, application, file type (e.g., document, spreadsheet, media object, etc.), and file classification (e.g., personal, corporate, confidential, etc.). In some embodiments the information collected by the DLP component 108 and communicated with the DLP Manager 104 may include the application and the user initiating the file system event.
Sarin discloses [ Claim 1. A method comprising: identifying, by a processor, a request by an application to access a file from a shared storage device over a network; enabling monitoring on a local data store to detect file system requests by the application in response to the identifying; creating a first profile of the file from the shared storage device, wherein the profile comprises metadata associated with the file; analyzing data associated with the file to determine if the data violates a data loss prevention (DLP) policy, wherein the analyzing the data comprises: detecting write operations to a new file stored to the local data store by the application], and [Claim 4. wherein the write operations comprise one of files save event, a file save-as event, a file close event, or a copy event].
Regarding claim 22, wherein: event logs generated by the third-party file access control service indicate changes to files of the list of files that are based at least in part on a requested type of access of the files of the list of files, and the change of the first file in response to which the plurality of analyzers are invoked is based at least in part on the requested type of access.
The combination of Manmohan and Sarin, and Kraus discloses:
Manmohan discloses [¶58, At block 514, the processing logic determines if the analyzed data violates the DLP policy 308. For example, the DLP policy 308 rule may specify one or more keywords (e.g., "confidential," "sensitive," "stock," names of specific diseases (e.g., "cancer," "HIV," etc.), etc.) for searching various files, messages and the like. In addition to keywords, the DLP policy 308 may include other rules for detecting presence of confidential data in information content being monitored. For example, in a financial organization, a DLP policy 308 may specify that if a message contains the word "confidential," further search of the message should be performed to determine whether the message includes customer data (e.g., a social security number, first name, last name, etc.) or other sensitive information (e.g., financial reports, source code, etc.). If the analyzed data does not violate the DLP policy 308, the processing logic, at block 512, allows the data transfer], and [¶68]
Sarin discloses [ Claim 1. A method comprising: identifying, by a processor, a request by an application to access a file from a shared storage device over a network; enabling monitoring on a local data store to detect file system requests by the application in response to the identifying; creating a first profile of the file from the shared storage device, wherein the profile comprises metadata associated with the file; analyzing data associated with the file to determine if the data violates a data loss prevention (DLP) policy, wherein the analyzing the data comprises: detecting write operations to a new file stored to the local data store by the application], and [Claim 4. wherein the write operations comprise one of files save event, a file save-as event, a file close event, or a copy event].
Kraus discloses: [¶240, In some embodiments, multiple data scanners 430 are configured to perform scanning for sensitive data 212 which meets a respective predefined sensitivity criterion 402 implemented in the scanner. The processor 110 is configured to set the scanning-condition 504 to enable zero or more scanners 430 for a particular iteration 414 based on at least one of the following: which sensitivity type 404 or combination of sensitivity types have been found by previous scanning, metadata 432 of the group 420 of stored items, the data security classification statistical measure 422, an iteration number 602 which indicates how many iterations 414 of the data sampling sequence have been performed, or a computational cost 510 that is associated with a particular scanner].
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Manmohan, Sarin, and Kraus, and Carlson in view of Narayanaswamy et al. (US 2017/0264640 A1), hereafter Narayanaswamy.
Regarding claims 9, and 19, Manmohan, Sarin, Kraus, and Carlson do not explicitly disclose, However, Narayanaswamy discloses wherein the first sensitive data item is a social security number and the second sensitive data item is a driver license number
Manmohan discloses: [¶58... message includes customer data (e.g., a social security number, first name, last name, etc.) or other sensitive information (e.g., financial reports, source code, etc.). If the analyzed data does not violate the DLP policy 308, the processing logic, at block 512, allows the data transfer].
Manmohan, Sarin, Kraus, and Carlson do not explicitly disclose, however Narayanaswamy discloses wherein the first sensitive data item is a social security number and the second sensitive data item is a driver license number [¶234, a PII content profile can include content inspection rules for detecting credit card information, social security data, and driver's license number).
Narayanaswamy is considered to be analogous to the claimed invention because it concerns the enforcement of data policies concerning data stores. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing data of the claimed invention to have modified the method of Manmohan, Sarin, Kraus, and Carlson to specifically detect the presence of a social security number and a driver’s license number as sensitive data items as taught by Narayanaswamy. One could have been motivated to do so in order to provide organizations implementing the method a higher level of control over user and data access ([Narayanaswamy 0079] technology disclosed provides organizations higher levels of control over their user and data access).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sarin (US2018/0278505) [0036, In one embodiment, examining module 106 may include a kernel mode driver that monitors process creation for the application and identifies the list of modules that are statically and/or dynamically loaded by the process. In some embodiments, after examining module 106 identifies the module, examining module 106 may notify a user mode component to inject a module that intercepts application programming interface (API) calls made by the application to the module that indicates that the application is capable of transferring files via the wireless technology standard], and [0055, In some embodiments, the systems described herein may include a combination of user mode components and/or kernel mode components. For example, at step 502 in FIG. 5, a kernel mode driver may monitor the list of modules loaded by a process to determine whether the application represented by the process is capable of transferring files via a wireless technology standard. At step 504, if the process loads a module that indicates file transfer capability, the kernel mode driver may notify a user mode component. At step 506, the user mode component may inject a module that intercepts network API calls made by the application to the module loaded earlier. At step 508, the module may notify the user mode component to monitor file system activity by the application in response to the module intercepting a network API call to open a connection via the wireless transfer protocol. At step 510, a file system driver may intercept a file open operation attempted by the application. At step 512, depending on whether the systems described herein determine that transferring the file would violate a data loss prevention policy, the file system driver may block, redirect, or allow the file open operation].
Kauffman (US8677448) [ 22) An organization may maintain multiple data stores 126 and may store a large number of documents in each data store 126. The stored documents may be frequently modified by different employees of the organization and new documents may be often added to the data stores 126. Hence, DLP policies 116 may request that data stores 126 be scanned frequently to prevent loss of confidential information], and [ (24) In one embodiment, data monitor 106 can monitor the documents for accesses of the documents. In one embodiment, if a document is accessed, e.g., by a user or by an application, data monitor 106 can store information associated with the access in storage, such as number of accesses store 108. Such information can include a timestamp associated with the access. In one embodiment, the data permission and access system 104 can maintain access statistics--for example in the number of accesses store 108--such as the number of users who have accessed the document or its content over a predetermined amount of time (e.g., 7 days), over its lifetime, or per some predetermined time interval (such as a month) over some period of time (such as a year)…], and [(50) Referring to FIG. 3, processing logic begins by identifying a data object on which to perform the risk score calculation at block 310. In some embodiments, the data object can be identified in a request received from a user. In some embodiments, the data object can be identified in a request received at predefined times for the data object. In some embodiments, the data object can be identified in a request received when the data object is created or modified. In some embodiments, the data object can be identified in a request received when the data object triggers an incident. In some embodiments, the data object can be a folder. If the data object is a folder, the files or hazards in the folder can be identified, and a risk score can be calculated for each of the files or hazards in the folder].
Vaikar (US9069992) (30) Content parser 120 may compute a fingerprint (or checksum, hash, signature, etc.) of the data and compare the computed fingerprint to a previously generated fingerprint that is included in the metadata. If the computed signature matches the previously generated signature, then the data has not been changed since the last scan was performed, and the result of the scan can be used without performing a new scan. In another embodiment, content parser 120 compares a timestamp of the last time a scan of the data was performed to an additional timestamp that identifies when the data was last modified. If the last scan was performed after the data was last modified, then no new scan of the data may be necessary. This may conserve system resources. Content parser 120 may also compare a version of the DLP policies that were enabled when the previous scan was performed to current versions of the DLP policies. If the DLP policies have been changed since the last scan was performed, then a new scan may be performed even if the contents of the data have not changed since the previous scan].
Huang (US2015/0261955) [0075] The scanning service may implement from scratch its own malware analysis sandbox. The scanning service may run multiple renderers (e.g., browsers, PDF readers, MS Office Word, Excel, PowerPoint) on top of its virtualization platform, such as a virtual machine executing within a cloud. The scanning service may then collect forensic information and then execute multiple analyzers against the collected data. At the end of this process, an aggregated FRM (Forensics Reporting Methodology) report may be returned to the API caller, such as the client terminal 105], and [¶¶62, 68].
AL-Masri (US2007/0050361) [0010] The present invention also provides a framework for controlling and managing the ranking of files based on the extraction of file and operating system features. Another characteristic of the present invention aims at ranking files within a computer system based on information contained within these files. Another characteristic of the present invention is to provide a scalable and extensible file ranking method which can apply to large number of files or large portions of computer systems. Another characteristic of the present invention is to provide a framework for the automatic discovery, ranking, and classification of files based on the establishment of ranking policies. Another characteristic of the present invention aims at providing a classification method. Other characteristics of the present invention will become apparent in the view of the following description and associated figures], and [ 0011] The present invention provides a method for adapting to automatically rank computer files at least including: a computer system examiner adapted to scan at least a portion of computer files; a repository builder adapted to establish plurality of collecting information; a policy organizer adapted to manage and adjust plurality of ranking policies; an analyzer adapted to evaluate and process files according to an established ranking policies; a ranker adapted to compute the ranking of files in accordance with the accumulation of weights and a ranking scheme; a classifier adapted to use taxonomies for categorizing files in accordance with plurality of ranking policies; and an integrator adapted to incorporate other supplementary operations serving as a connector with additional processes], and [¶22].
Amarendran (US2021/0026982) [0334] Additional aspects of the present disclosure relate to a system for sample-based sensitive data detection within an information management system. The system may include a content analyzer comprising one or more hardware processors. The content analyzer may be configured to: access a file identified as part of an information management job; determine that at least a portion of data within the file is included within a repetitive storage structure of the file; analyze a first portion of the file to determine whether the first portion includes sensitive data; and determine whether the file includes sensitive data based on the analysis of the first portion without analyzing a second portion of the file], and [abstract].
Duncan et al. (US 2006/0048224 A1) discloses a method and apparatus for detecting sensitive digital information and enforcing information security policies via a software permission wrapper.
Narayanaswamy et al. (US 2017/0264640 A1)[ ¶¶189-190, FIG.1C, event logs from external sources can be provided to a security system, event log entries including fields such as user identity, timestamp, and activity data).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5:30pm.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. 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.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496