Prosecution Insights
Last updated: August 17, 2026
Application No. 18/896,239

Method for Automatically Issuing Incident Notifications

Non-Final OA §102§103
Filed
Sep 25, 2024
Examiner
BAZNA, JUDY
Art Unit
2495
Tech Center
2400 — Computer Networks
Assignee
Varonis Systems Inc.
OA Round
1 (Non-Final)
68%
Grant Probability
Favorable
1-2
OA Rounds
1y 3m
Est. Remaining
95%
With Interview

Examiner Intelligence

Grants 68% — above average
68%
Career Allowance Rate
19 granted / 28 resolved
+9.9% vs TC avg
Strong +27% interview lift
Without
With
+27.1%
Interview Lift
resolved cases with interview
Typical timeline
3y 1m
Avg Prosecution
9 currently pending
Career history
46
Total Applications
across all art units

Statute-Specific Performance

§101
5.0%
-35.0% vs TC avg
§103
77.0%
+37.0% vs TC avg
§102
10.1%
-29.9% vs TC avg
§112
5.8%
-34.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 28 resolved cases

Office Action

§102 §103
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 . Information Disclosure Statement The information disclosure statement (IDS) submitted by applicant dated 07/31/2025 and 03/04/2025 and 09/25/2024 have been considered by the examiner. Claim Rejections - 35 USC § 102 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 (i.e., changing from AIA to pre-AIA ) 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. 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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. Claim(s) 1, 2, 4, 5, 6, 8, 9, 10 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by NICKL (US 20230162060 A1). Regrading claim 1, NICKL teaches a computer-implemented method for automatically issuing a data incident notification, the method comprising: determining an incident has occurred with respect to at least one data storage device that stores a plurality of data items (Para [0082]. Para [0285]. FIGS. 1A and 1B: When protected information is included in managed data affected by a data breach event, actual or potential disclosure of the protected information is possible. As such, upon notification of a data breach in an enterprise IT network that includes protected information, the manager of such network will generally be required to undertake one or more compliance-related activities associated with the subject protected information. Beginning at 102 of FIG. 1A, a (first) date file collection associated with a data breach event is received by at least one computer (e.g., a server or cloud computing system). The data file collection can be generated by analysis of the data breach event. For example, the data file collection can be derived from a bulk data file collection stored on with an enterprise IT network.); obtaining a data item and entity index for the at least one data storage device, wherein, for each data storage device, the data item and entity index comprises a plurality of index entries, wherein each index entry comprises an identifier for one data item of the plurality of data items stored by the data storage device together with an entity identifier for each entity named within content of each data item (Para [0249]- [0250]. Para [0271]- [0277]: The data file collection can be generated by analysis of the data breach event. For example, the data file collection can be derived from a bulk data file collection stored on with an enterprise IT network. The methodology herein is configured to identify tabular data in a data file, identify one or more relationships between and among the tabular data, and associate the tabular data with the identified relationships. The system can then extract the tabular data along with the identified relationships. The system can be configured to identify the nature and content of the data and to extract any relationships therefrom. The data file can include more than one protected information data element and/or can be associated with more than one entity identification. The collection of information available for each identified entity can comprise at least all protected information identified for each identified entity that was associated with the data breach event.); generating, using the obtained data item and entity index for the at least one data storage device, a notification list comprising each data item that names at least one entity, and the corresponding entity identifier of the entity (Para [0249]. Para [0278]-[0281]: the generated compliance-related database can then be used in compliance-related activities associated with a data breach event. In this regard, the compliance-related activities can comprise one or more of receiving a plurality of compliance-related requirements associated with a data breach event, determining whether one or more of the pluralities of compliance requirements are relevant to one or more of the entities in the compliance-related database wherein the data file can include more than one protected information data element and/or can be associated with more than one entity identification. In a non-limiting list, these can include: full name, first name only, first initial and last name, last name only, e.g., and any others that are relevant in context- and performing compliance-related activities associated with each to the identified entities. In this regard, a reporting obligation associated with an identified entity is determined for an identified entity.); and determining, for each entity identifier in the notification list, whether to generate a data incident notification (Para [0278]- [0281]: determining whether one or more of the pluralities of compliance requirements are relevant to one or more of the entities in the compliance-related database and performing compliance-related activities associated with each to the identified entities. Methods herein can be configured to generate automatic notifications of the data breach to each identified entity as required by each applicable laws, rules, regulations, policies, or contractual obligations. In this regard, a reporting obligation associated with an identified entity is determined for an identified entity.). Regrading claim 2, NICKL teaches the method of claim 1 further comprising, for at least one entity identifier in the notification list (Para [0278]- [0281]: determining whether one or more of the pluralities of compliance requirements are relevant to one or more of the entities in the compliance-related database and performing compliance-related activities associated with each to the identified entities.), issuing a data incident notification responsive to determining a data incident notification is to be generated for the at least one entity identifier (Para [0277]- [0281]: a collection of database information for each entity identified in the review process. The collection of information available for each identified entity can comprise at least all protected information identified for each identified entity that was associated with the data breach event, related or duplicate entities identified, and data files associated with each identified entity that do not comprise protected information. The generated compliance-related database can then be used in compliance-related activities associated with a data breach event. The systems and methods herein can be configured to generate automatic notifications of the data breach to each identified entity as required by each applicable laws, rules, regulations, policies, or contractual obligations. In this regard, a reporting obligation associated with an identified entity is determined for an identified entity.). Regrading claim 4, NICKL teaches the method of claim 1 wherein determining an incident has occurred comprises: receiving an alert that a data policy associated with at least one data item stored by the at least one data storage device has been violated (Para [0085]. Para [0278]. Para [0281]: upon notification of a data breach from a data file stored in an enterprise IT network that includes protected information, the manager of such network will generally be required to undertake one or more compliance-related activities associated with the subject protected information. determining whether one or more of the pluralities of compliance requirements are relevant to one or more of the entities in the compliance-related database and performing compliance-related activities associated with each to the identified entities. Methods herein can be configured to generate automatic notifications of the data breach to each identified entity as required by each applicable laws, rules, regulations, policies, or contractual obligations. In this regard, a reporting obligation associated with an identified entity is determined for an identified entity.). Regrading claim 5, NICKL teaches the method of claim 4 wherein generating a notification list comprises: identifying, in the index, an index entry corresponding to the at least one data item (Para [0249]- [0250]. Para [0271]- [0277]: The data file collection can be generated by analysis of the data breach event. For example, the data file collection can be derived from a bulk data file collection stored on with an enterprise IT network. The methodology herein is configured to identify tabular data in a data file, identify one or more relationships between and among the tabular data, and associate the tabular data with the identified relationships. The system can then extract the tabular data along with the identified relationships. The system can be configured to identify the nature and content of the data and to extract any relationships therefrom. The data file can include more than one protected information data element and/or can be associated with more than one entity identification. The collection of information available for each identified entity can comprise at least all protected information identified for each identified entity that was associated with the data breach event.); selecting, from each identified index entry, each index entry comprising an entity identifier (Para [0249]- [0250]. Para [0271]- [0277]: The data file collection can be generated by analysis of the data breach event. For example, the data file collection can be derived from a bulk data file collection stored on with an enterprise IT network. The methodology herein is configured to identify tabular data in a data file, identify one or more relationships between and among the tabular data, and associate the tabular data with the identified relationships. The system can then extract the tabular data along with the identified relationships. The system can be configured to identify the nature and content of the data and to extract any relationships therefrom. The data file can include more than one protected information data element and/or can be associated with more than one entity identification. The collection of information available for each identified entity can comprise at least all protected information identified for each identified entity that was associated with the data breach event.); and extracting, for each selected index entry, the identifier for the data item and the entity identifier for each entity named within content of the data item (Para [0249]. Para [0278]-[0281]: The system can then extract the tabular data along with the identified relationships. The system can be configured to identify the nature and content of the data and to extract any relationships therefrom. wherein the data file can include more than one protected information data element and/or can be associated with more than one entity identification. In a non-limiting list, these can include: full name, first name only, first initial and last name, last name only, e.g., and any others that are relevant in context. In this regard, a reporting obligation associated with an identified entity is determined for an identified entity.) Regrading claim 6, NICKL teaches the method of claim 5 wherein determining, for each entity identifier in the notification list, whether to generate a data incident notification comprises: retrieving, for the entity identifier, a notification policy for the entity corresponding to the entity identifier, wherein the notification policy comprises a condition for generating a data incident notification (Para [0278]- [0281]: determining whether one or more of the pluralities of compliance requirements are relevant to one or more of the entities in the compliance-related database and performing compliance-related activities associated with each to the identified entities. Methods herein can be configured to generate automatic notifications of the data breach to each identified entity as required by each applicable laws, rules, regulations, policies, or contractual obligations. In this regard, a reporting obligation associated with an identified entity is determined for an identified entity.). Regrading claim 8, NICKL teaches the method of claim 6 wherein retrieving a notification policy for the entity comprises: retrieving a notification policy that is pre-determined for the entity (Para [0278]- [0281]: determining whether one or more of the pluralities of compliance requirements are relevant to one or more of the entities in the compliance-related database and performing compliance-related activities associated with each to the identified entities. Methods herein can be configured to generate automatic notifications of the data breach to each identified entity as required by each applicable laws, rules, regulations, policies, or contractual obligations. In this regard, a reporting obligation associated with an identified entity is determined for an identified entity.). Regrading claim 9, NICKL teaches the method of claim 6 wherein retrieving a notification policy for the entity comprises: determining a risk level associated with the entity (Para [0280]- [0281]: provide a risk assessment based on the nature and scope of a data breach as shown by a compliance-related database. These risk assessments provide specific information to an enterprise regarding the severity of the data breach relative to applicable laws, rules, regulations, policies, or contractual obligations. The data risk assessment can provide information associated with the level of protected information associated with the data breach. Such information can be consolidated into a report form or otherwise used for “after action” activities associated with compliance-related activities. The systems and methods herein can be configured to generate automatic notifications of the data breach to each identified entity as required by each applicable laws, rules, regulations, policies, or contractual obligations.); and retrieving a notification policy based on the determined risk level (Para [0280]- [0281]: provide a risk assessment based on the nature and scope of a data breach as shown by a compliance-related database. These risk assessments provide specific information to an enterprise regarding the severity of the data breach relative to applicable laws, rules, regulations, policies, or contractual obligations. The data risk assessment can provide information associated with the level of protected information associated with the data breach. Such information can be consolidated into a report form or otherwise used for “after action” activities associated with compliance-related activities. The systems and methods herein can be configured to generate automatic notifications of the data breach to each identified entity as required by each applicable laws, rules, regulations, policies, or contractual obligations.). Regrading claim 10, NICKL teaches the method of claim 9 wherein determining a risk level associated with the entity comprises determining any of: a risk level of the entity; a risk level of a role performed by the entity; a risk level of a group of which the entity is a member (Para [0281]). Claim Rejections - 35 USC § 103 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 (i.e., changing from AIA to pre-AIA ) 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. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claim(s) 3, 7 are rejected under 35 U.S.C. 103 as being unpatentable over NICKL (US 20230162060 A1) in view of Kiang (US 20140026181 A1). Regrading claim 3, NICKL teaches the method of claim 1. NICKL does not explicitly disclose further comprising: transmitting, responsive to determining a data incident notification is to be generated, the generated notification list to a system administrator, thereby enabling the system administrator to notify each entity about the data items in which they are named and that are subject to the incident. Kiang teaches further comprising: transmitting, responsive to determining a data incident notification is to be generated, the generated notification list to a system administrator, thereby enabling the system administrator to notify each entity about the data items in which they are named and that are subject to the incident (FIG. 2. Para [0072]. Para [0082]. Para [0096]. Para [0179]: Administrators may be able to satisfy the security use case of DLP, where notification server 250 provide notifications of activities that occur in the online collaboration environment in real time or near real time to users 208. In addition, users, collaborators, or select users can be notified in real time or near real-time of these actions or activities.). Thus, 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 invention of NICKL with the teachings of Kiang to include further comprising: transmitting, responsive to determining a data incident notification is to be generated, the generated notification list to a system administrator, thereby enabling the system administrator to notify each entity about the data items in which they are named and that are subject to the incident in order to protects sensitive information in online collaboration environments. Regrading claim 7, NICKL teaches the method of claim 6. NICKL does not explicitly disclose wherein when the condition for generating a data incident notification is satisfied, the method further comprises: transmitting, for the entity, the identifier for each data item in which the entity is named, and the entity identifier to a system administrator Kiang teaches wherein when the condition for generating a data incident notification is satisfied, the method further comprises: transmitting, for the entity, the identifier for each data item in which the entity is named, and the entity identifier to a system administrator (FIG. 2. Para [0072]. Para [0082]. Para [0096]. Para [0179]: Administrators may be able to satisfy the security use case of DLP, where notification server 250 provide notifications of activities that occur in the online collaboration environment in real time or near real time to users 208. In addition, users, collaborators, or select users can be notified in real time or near real-time of these actions or activities.). Thus, 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 invention of NICKL with the teachings of Kiang to include further comprising: transmitting, responsive to determining a data incident notification is to be generated, the generated notification list to a system administrator, thereby enabling the system administrator to notify each entity about the data items in which they are named and that are subject to the incident in order to protects sensitive information in online collaboration environments. Claim(s) 11 is rejected under 35 U.S.C. 103 as being unpatentable over NICKL (US 20230162060 A1) in view of Kiang (US 20140026181 A1) in view of Zhang (US 20180144138 A1). Regrading claim 11, NICKL teaches the method of claim 9. NICKL does not explicitly disclose wherein, when the notification list contains two or more entities, the identifier for each data item in which each entity is named, and the entity identifier to a system administrator. Kiang teaches further comprising: transmitting, responsive to determining a data incident notification is to be generated, the generated notification list to a system administrator, thereby enabling the system administrator to notify each entity about the data items in which they are named and that are subject to the incident (FIG. 2. Para [0072]. Para [0082]. Para [0096]. Para [0179]: Administrators may be able to satisfy the security use case of DLP, where notification server 250 provide notifications of activities that occur in the online collaboration environment in real time or near real time to users 208. In addition, users, collaborators, or select users can be notified in real time or near real-time of these actions or activities.) Thus, 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 invention of NICKL with the teachings of Kiang to include further comprising: transmitting, responsive to determining a data incident notification is to be generated, the generated notification list to a system administrator, thereby enabling the system administrator to notify each entity about the data items in which they are named and that are subject to the incident in order to protects sensitive information in online collaboration environments. NICKL in view of Kiang does not explicitly disclose the method further comprises: ordering the two or more entities into an order based on the determined risk level of the entities; and transmitting, in a same order as the order of the entities. Zhang teaches the method further comprises: ordering the two or more entities into an order based on the determined risk level of the entities; and transmitting, in a same order as the order of the entities (Para [0012]-[0014]: The linking of entities in the graph database allows embodiments to perform accurate risk ranking of entities using defined risk scores of certain other entities. Embodiments may, for example, start with first entities that can be accurately risk ranked (e.g., lowest level entities) in order to automatically risk rank other entities that are either directly or indirectly linked to the first entity (e.g., higher level entities). Once entities have been risk ranked (e.g., by physically transforming data within the graph database), some embodiments may send an alert if certain risk scores are determined to be over a threshold value.). Thus, 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 invention of NICKL in view of Kiang with the teachings of Zhang to include the method further comprises: ordering the two or more entities into an order based on the determined risk level of the entities; and transmitting, in a same order as the order of the entities in order to prioritizing risk management actions for highest-priority data. Claim(s) 12,13,15 are rejected under 35 U.S.C. 103 as being unpatentable over NICKL (US 20230162060 A1) in view of Asheghian (US9064130B1). Regrading claim 12, NICKL teaches the method of claim 1. NICKL does not explicitly disclose wherein determining an incident has occurred comprises: receiving information from an external source that an incident has occurred with respect to the at least one data storage device. Asheghian teaches wherein determining an incident has occurred comprises: receiving information from an external source that an incident has occurred with respect to the at least one data storage device (Fig. 4. Col 7 lines 20-29, Col 7 lines 42-49: Network based DLP system 430 may protect data that is present on network storage 415 and/or data that is present on storage devices 425, 450 of individual computing devices 410, 440. Network based DLP system 430 may also send notifications to one or more host based DLP systems 435, 445 if certain software or activities are detected on the computing devices.). Thus, 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 invention of NICKL with the teachings of Asheghian to include wherein determining an incident has occurred comprises: receiving information from an external source that an incident has occurred with respect to the at least one data storage device in order to manage and centralize data protection in multiple storage environments to prevent data loss. Regrading claim 13, NICKL in view of Asheghian the method of claim 12 wherein generating a notification list comprises: identifying, in the index, each index entry comprising an entity identifier (NICKL Para [0277]-[0278]: provide a collection of database information for each entity identified in the review process. The collection of information available for each identified entity can comprise at least all protected information identified for each identified entity that was associated with the data breach event. A level of confidence can be presented for each data file associated with an identified entity, where the level of confidence can serve as a way to identify compliance-related database information. The generated compliance-related database can then be used in compliance-related activities associated with a data breach event. In this regard, the compliance-related activities can comprise one or more of receiving a plurality of compliance-related requirements associated with a data breach event, determining whether one or more of the plurality of compliance requirements are relevant to one or more of the entities in the compliance-related database, and performing compliance-related activities associated with each to the identified entities.); and extracting, for each identified index entry, the identifier for the data item and the entity identifier for each entity named within content of the data item (NICKL Para [0277]-[0278]: provide a collection of database information for each entity identified in the review process. The collection of information available for each identified entity can comprise at least all protected information identified for each identified entity that was associated with the data breach event. A level of confidence can be presented for each data file associated with an identified entity, where the level of confidence can serve as a way to identify compliance-related database information. The generated compliance-related database can then be used in compliance-related activities associated with a data breach event. In this regard, the compliance-related activities can comprise one or more of receiving a plurality of compliance-related requirements associated with a data breach event, determining whether one or more of the pluralities of compliance requirements are relevant to one or more of the entities in the compliance-related database, and performing compliance-related activities associated with each to the identified entities.). Regrading claim 15, NICKL teaches a system for automatically issuing a data incident notification, the system comprising: a data item and entity index for each data storage device, wherein, for each data storage device, the data item and entity index comprises a plurality of index entries, wherein each index entry comprises an identifier for one data item of the plurality of data items stored by the data storage device together with an entity identifier for each entity named within content of each data item items (Para [0277]-[0278]: provide a collection of database information for each entity identified in the review process. The collection of information available for each identified entity can comprise at least all protected information identified for each identified entity that was associated with the data breach event. A level of confidence can be presented for each data file associated with an identified entity, where the level of confidence can serve as a way to identify compliance-related database information. The generated compliance-related database can then be used in compliance-related activities associated with a data breach event. In this regard, the compliance-related activities can comprise one or more of receiving a plurality of compliance-related requirements associated with a data breach event, determining whether one or more of the pluralities of compliance requirements are relevant to one or more of the entities in the compliance-related database, and performing compliance-related activities associated with each to the identified entities.); and at least one processor coupled to memory, arranged for: determining an incident has occurred with respect to at least one of the data storage devices items (Para [0082]. Para [0285]. FIGS. 1A and 1B: When protected information is included in managed data affected by a data breach event, actual or potential disclosure of the protected information is possible. As such, upon notification of a data breach in an enterprise IT network that includes protected information, the manager of such network will generally be required to undertake one or more compliance-related activities associated with the subject protected information. Beginning at 102 of FIG. 1A, a (first) date file collection associated with a data breach event is received by at least one computer (e.g., a server or cloud computing system). The data file collection can be generated by analysis of the data breach event. For example, the data file collection can be derived from a bulk data file collection stored on with an enterprise IT network.); obtaining the data item and entity index for the at least one data storage device where the incident has occurred (Para [0249]- [0250]. Para [0271]- [0277]: The data file collection can be generated by analysis of the data breach event. For example, the data file collection can be derived from a bulk data file collection stored on with an enterprise IT network. The methodology herein is configured to identify tabular data in a data file, identify one or more relationships between and among the tabular data, and associate the tabular data with the identified relationships. The system can then extract the tabular data along with the identified relationships. The system can be configured to identify the nature and content of the data and to extract any relationships therefrom. The data file can include more than one protected information data element and/or can be associated with more than one entity identification. The collection of information available for each identified entity can comprise at least all protected information identified for each identified entity that was associated with the data breach event.); generating, using the obtained data item and entity index for the at least one data storage device, a notification list comprising each data item that names at least one entity, and the corresponding entity identifier of the entity (Para [0249]. Para [0278]-[0281]: the generated compliance-related database can then be used in compliance-related activities associated with a data breach event. In this regard, the compliance-related activities can comprise one or more of receiving a plurality of compliance-related requirements associated with a data breach event, determining whether one or more of the pluralities of compliance requirements are relevant to one or more of the entities in the compliance-related database wherein the data file can include more than one protected information data element and/or can be associated with more than one entity identification. In a non-limiting list, these can include: full name, first name only, first initial and last name, last name only, e.g., and any others that are relevant in context- and performing compliance-related activities associated with each to the identified entities. In this regard, a reporting obligation associated with an identified entity is determined for an identified entity.); and determining, for each entity identifier in the notification list, whether to generate a data incident notification (Para [0278]- [0281]: determining whether one or more of the pluralities of compliance requirements are relevant to one or more of the entities in the compliance-related database and performing compliance-related activities associated with each to the identified entities. Methods herein can be configured to generate automatic notifications of the data breach to each identified entity as required by each applicable laws, rules, regulations, policies, or contractual obligations. In this regard, a reporting obligation associated with an identified entity is determined for an identified entity.). NICKL does not explicitly disclose a plurality of data storage devices, each data storage device storing a plurality of data items. Asheghian teaches a plurality of data storage devices, each data storage device storing a plurality of data items (Fig. 4. Col 7 lines 20-29: Network based DLP system 430 may protect data that is present on network Storage 415 and/or data that is present on storage devices 425,450). Thus, 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 invention of NICKL with the teachings of Asheghian to include a plurality of data storage devices, each data storage device storing a plurality of data items in order to manage and centralize data protection in multiple storage environments to ensure sensitive information is stored in secure and isolated locations. Claim(s) 14 is rejected under 35 U.S.C. 103 as being unpatentable over NICKL (US 20230162060 A1) in view of Kiang (US 20140026181 A1). Regrading claim 14, NICKL teaches the method of claim 13. NICKL does not explicitly disclose wherein determining, for each entity identifier in the notification list, whether to generate a data incident notification comprises: automatically transmitting the generated notification list to a system administrator, thereby enabling the system administrator to notify each entity about the data items in which they are named and that are subject to the incident. Kiang teaches wherein determining, for each entity identifier in the notification list, whether to generate a data incident notification comprises: automatically transmitting the generated notification list to a system administrator, thereby enabling the system administrator to notify each entity about the data items in which they are named and that are subject to the incident (FIG. 2. Para [0072]. Para [0082]. Para [0096]. Para [0179]: Administrators may be able to satisfy the security use case of DLP, where notification server 250 provide notifications of activities that occur in the online collaboration environment in real time or near real time to users 208. In addition, users, collaborators, or select users can be notified in real time or near real-time of these actions or activities.) Thus, 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 invention of NICKL with the teachings of Kiang to include further comprising: transmitting, responsive to determining a data incident notification is to be generated, the generated notification list to a system administrator, thereby enabling the system administrator to notify each entity about the data items in which they are named and that are subject to the incident in order to protects sensitive information in online collaboration environments. Claim(s) 16-19 are rejected under 35 U.S.C. 103 as being unpatentable over NICKL (US 20230162060 A1) in view of Bar-or (US 20040139145 A1). Regrading claim 16, NICKL teaches a computer-implemented method for automatically generating a data item and entity index for use in issuing data incident notifications, the method comprising: obtaining, for the new data item, an identifier for the new data item (Para [0249]- [0250]. Para [0271]- [0277]: The data file collection can be generated by analysis of the data breach event. For example, the data file collection can be derived from a bulk data file collection stored on with an enterprise IT network. The methodology herein is configured to identify tabular data in a data file, identify one or more relationships between and among the tabular data, and associate the tabular data with the identified relationships. The system can then extract the tabular data along with the identified relationships. The system can be configured to identify the nature and content of the data and to extract any relationships therefrom. The data file can include more than one protected information data element and/or can be associated with more than one entity identification. The collection of information available for each identified entity can comprise at least all protected information identified for each identified entity that was associated with the data breach event.); obtaining an entity identifier for each entity named within content of the new data item (Para [0249]. Para [0278]-[0281]: the generated compliance-related database can then be used in compliance-related activities associated with a data breach event. In this regard, the compliance-related activities can comprise one or more of receiving a plurality of compliance-related requirements associated with a data breach event, determining whether one or more of the pluralities of compliance requirements are relevant to one or more of the entities in the compliance-related database wherein the data file can include more than one protected information data element and/or can be associated with more than one entity identification. In a non-limiting list, these can include: full name, first name only, first initial and last name, last name only, e.g., and any others that are relevant in context- and performing compliance-related activities associated with each to the identified entities. In this regard, a reporting obligation associated with an identified entity is determined for an identified entity.); and adding an index entry to the data item and entity index, wherein the index entry comprises the identifier for the new data item and the entity identifier for each entity named within content of the new data item (Para [0249]- [0250]. Para [0271]- [0277]: The data file collection can be generated by analysis of the data breach event. For example, the data file collection can be derived from a bulk data file collection stored on with an enterprise IT network. The methodology herein is configured to identify tabular data in a data file, identify one or more relationships between and among the tabular data, and associate the tabular data with the identified relationships. The system can then extract the tabular data along with the identified relationships. The system can be configured to identify the nature and content of the data and to extract any relationships therefrom. The data file can include more than one protected information data element and/or can be associated with more than one entity identification. The collection of information available for each identified entity can comprise at least all protected information identified for each identified entity that was associated with the data breach event.). Bar-or teaches receiving an update whenever a new data item has been stored in a data storage device (Claim 39: receiving a new data input from the client device attached to the scalable distributed storage apparatus through the independent node; determining whether the new data input is new data to be stored or an update to previously stored data, and based on that determination, storing the new data input on the scalable distributed storage apparatus, if it is new data to be stored, or updating the previously stored data on the scalable distributed is storage apparatus, if it is an update to previously stored data; and transmitting a notification to the attached client device if the storing of the new data input was successful.). Thus, 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 invention of NICKL with the teachings of Bar-or to include receiving an update whenever a new data item has been stored in a data storage device order to ensure the database has the latest configuration changes to maintain operational effectiveness. Regrading claim 17, NICKL in view of Bar-or teaches the method of claim 16 wherein obtaining an entity identifier comprises: obtaining a list of entities and corresponding entity identifiers (Bar-or Claim 39. NICKL Para [0249]. Para [0308]. Fig. 3I: The entity list window 311 shows the entity first and last names and such information can be expanded based on additional user input. Various entity identifiers found in a data file can be used to align or link one or more protected information data elements in that data file to a single entity.); determining whether any entities in the obtained list appear in the content of the new data item (Bar-or Claim 39. NICKL Para [0249]. Para [0308]. Fig. 3I: The entity list window 311 shows the entity first and last names and such information can be expanded based on additional user input. The relevant information can be automatically extracted from the data file and added to the database. Various entity identifiers found in a data file can be used to align or link one or more protected information data elements in that data file to a single entity.); and extracting from the list, when an entity appears in the content, the entity identifier of the entity (Bar-or Claim 39. NICKL Para [0249]. Para [0308]. Fig. 3I: The entity list window 311 shows the entity first and last names and such information can be expanded based on additional user input. The relevant information can be automatically extracted from the data file and added to the database. Various entity identifiers found in a data file can be used to align or link one or more protected information data elements in that data file to a single entity.). Regrading claim 18, NICKL in view of Bar-or teaches the method of claim 16 further comprising: adding information about a notification policy for the entity in the index entry, wherein the notification policy comprises a condition for generating a data incident notification (NICKL Para [0278]- [0281]: determining whether one or more of the pluralities of compliance requirements are relevant to one or more of the entities in the compliance-related database and performing compliance-related activities associated with each to the identified entities. Methods herein can be configured to generate automatic notifications of the data breach to each identified entity as required by each applicable laws, rules, regulations, policies, or contractual obligations. In this regard, a reporting obligation associated with an identified entity is determined for an identified entity.). Regrading claim 19, NICKL in view of Bar-or teaches the method of claim 16 further comprising: adding information about a risk level associated with the entity to the index entry (NICKL Para [0280]- [0281]: provide a risk assessment based on the nature and scope of a data breach as shown by a compliance-related database. These risk assessments provide specific information to an enterprise regarding the severity of the data breach relative to applicable laws, rules, regulations, policies, or contractual obligations. The data risk assessment can provide information associated with the level of protected information associated with the data breach. Such information can be consolidated into a report form or otherwise used for “after action” activities associated with compliance-related activities. The systems and methods herein can be configured to generate automatic notifications of the data breach to each identified entity as required by each applicable laws, rules, regulations, policies, or contractual obligations.). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUDY BAZNA whose telephone number is (703)756-1258. The examiner can normally be reached Monday - Friday 08:30 AM-05: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, Farid Homayounmehr can be reached at (571) 272-3739. 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. /JUDY BAZNA/Examiner, Art Unit 2495 /FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495
Read full office action

Prosecution Timeline

Sep 25, 2024
Application Filed
Jul 01, 2026
Non-Final Rejection mailed — §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12641098
METHOD AND APPARATUS FOR DETECTING ANOMALIES OF AN INFRASTRUCTURE IN A NETWORK
4y 2m to grant Granted May 26, 2026
Patent 12585784
SYSTEM FOR COMPONENT-LEVEL THREAT ASSESSMENT IN A COMPUTING ENVIRONMENT
2y 11m to grant Granted Mar 24, 2026
Patent 12579261
MANAGING INFERENCE MODELS IN VIEW OF RECONSTRUCTABILITY OF SENSITIVE INFORMATION
1y 9m to grant Granted Mar 17, 2026
Patent 12572643
CIRCUIT AND METHOD FOR DETECTING A FAULT INJECTION ATTACK IN AN INTEGRATED CIRCUIT
3y 6m to grant Granted Mar 10, 2026
Patent 12549335
COORDINATING DATA ACCESS AMONG MULTIPLE SERVICES
3y 4m to grant Granted Feb 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
68%
Grant Probability
95%
With Interview (+27.1%)
3y 1m (~1y 3m remaining)
Median Time to Grant
Low
PTA Risk
Based on 28 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month