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 .
DETAILED ACTION
This action is in response to the communication filed on 04/22/2024.
Claims 1-20 are under examination.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2-3, 7, 12-13 and 17 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 2-3 and 12-13 recite the limitation "the security enforcement system" in line 4 and claims 7 and 17 recite the limitation "the security evaluation platform" in line 3. There is insufficient antecedent basis for this limitation in the claim.
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.
Claims 1-7, 9-17 and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Janssen (US 2016/0127417 A1) and Chapman (US 2016/0234245 A1).
Regarding claim 1, Janssen discloses A computerized method for implementing multi-context data loss prevention [par. 0026-0028, data loss prevention rules], the method comprising: storing, by a security enforcement platform, one or more multi-context data loss prevention (MCDLP) security policies for securing protected information included in data assets [par. 0055, determine network security policy (related to an asset) using a network security policy computer knowledge base]; receiving, by the security enforcement platform [par. 0044, SOC (security operation center)], an activity event corresponding to at least one data asset [par. 0044, SOC monitor communications, determine a network security policy, process network security events to determine actions]; determining whether the activity event is authorized by the one or more MCDLP security policies [par. 0044, determine user devices to transmit notifications based on network security events and/or user authorization hierarchies], at least in part, by: analyzing role data corresponding to at least one end-user associated with the activity event [par. 0027, “the data loss prevention rule, such as in example 330 and 340 in FIG. 3, if the IP address is “normal” for the user's role, based on accumulated IP address counts for all users with the same role, can be no action”]; scanning the at least one data asset to determine if the at least one data asset comprises protected information [pars. 0121-0122, the network data packet can include information about a company asset (e.g., a computer file containing confidential information). The asset can be associated with a department within the company, TICAP can detect the network data packet, generate an network security event based on the network data packet and determine an action corresponding to a network security policy ]; and determining if a verification response was received in connection with the activity event [par. 0008, determining a user device to notify based on a user authorization hierarchy and an asset corresponding to the network security event… receiving a response from the user device, determining commands based on the response, and transmitting the commands to the security appliance]; and executing, by the security enforcement platform, one or more remediation functions in response to determining that the activity event violates the one or more MCDLP security policies [pars. 0123-0125, SOC can receive the network security event, process the network security event using the network security policy and determine an action, permit the user to authorize the network data packet (e.g., permanently or temporarily), deny the network data packet, or defer the decision to another user].
Janssen does not explicitly disclose analyzing status data corresponding to the at least one end-user associated with the activity event.
However, Chapman teaches analyzing status data corresponding to the at least one end-user associated with the activity event [par. 0047, triggering events include a member of the organization violating a data loss prevention rule, a member of the organization forwarding a suspicious e-mail to the help desk, a user completing training, a user changing jobs status or roles, managers having events triggered based on their subordinates, a user getting locked out of a system for too many login attempts].
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to incorporate the teaching of Chapman into the teaching of Janssen with the motivation of reducing organizational susceptibility to social engineering as taught by Chapman [Chapman: par. 0005].
Regarding claim 2, the rejection of claim 1 is incorporated.
Janssen further discloses the security enforcement system remotely monitors activity events originating from a plurality of accounts over a network [par. 0039, “remote computer device 130 can monitor the instance of the database, determine that a suspicious set of user device events or communications occurred (e.g., an unusual operating system event followed by an unusual network communication, abnormal user behavior, etc.), and send a communication to TICAP 140 indicating the suspicious set of user device events or communications, as described above for user computer device 110”], and remotely enforces the one or more MCDLP security policies on the data assets; the at least one data asset is stored on an account that is remotely monitored by the security enforcement system; the activity event originates from the account and is provided to the security enforcement system over the network; and in response to determining that the activity event is not compliant with the one or more MCDLP security policies, the security enforcement system transmits one or more commands over the network to the account in connection with executing the one or more remediation functions [par. 0043, “TICAP 140 can monitor the instance of the database, determine that a suspicious set of user device events or communications occurred (e.g., an unusual network communication from a first device followed by an unusual network communication from a second device, abnormal user behavior, etc.), send information corresponding to the suspicious set of user device events or communications to SOC 150, and/or determine to block or allow a communication based on the suspicious set of user device events or communications”].
Chapman further disclose the security enforcement platform is configured to secure protected information included in data assets stored on one or more software-as- a-service (SaaS) platforms, remotely enforces the one or more security policies on the data assets stored across the plurality of SaaS accounts [par. 0017, the appliance is configured to communicate with an exterior platform such as, for example, a software as a service platform... The appliance gathers identifying information and/or contact information, e.g., e-mail addresses, telephone numbers, mobile telephone numbers, social media identifiers, such as FACEBOOOK account IDs, TWITTER user names, etc., for example, of employees of the organization, such as from directories, databases, management systems, messaging systems, and incident response systems of the organization].
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to incorporate the teaching of Chapman into the teaching of Janssen with the motivation of reducing organizational susceptibility to social engineering as taught by Chapman [Chapman: par. 0005].
Regarding claim 3, the rejection of claim 1 is incorporated.
Janssen further discloses the security enforcement platform is configured to secure protected information included data assets stored within an entity system such that: the security enforcement system monitors activity events originating from one or more entity user accounts within the entity system [par. 0024, “the user device events can be associated with a user identifier that is associated with a specific user. In some embodiment, users can be required to log in to a user device, and the login information provided by the user can be used to determine the user identifier for that user”, par. 0029, monitor the instance of the database, determine that a suspicious set of user device events or communications occurred], and enforces the one or more MCDLP security policies on the data assets stored within the entity system [par. 0101, the action can be to enforce a network security policy by sending commands to one or more TICAPs]; and in response to determining that the activity event is not compliant with the one or more MCDLP policies, the security enforcement system transmits one or more commands within the entity system in connection with executing the one or more remediation functions [pars. 0123-0125, SOC can receive the network security event, process the network security event using the network security policy and determine an action, permit the user to authorize the network data packet (e.g., permanently or temporarily), deny the network data packet, or defer the decision to another user].
Regarding claim 4, the rejection of claim 1 is incorporated.
Janssen further discloses each of the one or more MCDLP security policies include: a first policy condition identifying an activity event type that is applicable to a corresponding MCDLP security policy, wherein the activity event type corresponds to a share event [par. 0025, If the user has a role like “Human Resources” then emailing employee names in bulk might be typical behavior, but if the user has the role of “Janitor” then this behavior would not be normal]; a second policy condition identifying one or more roles that are applicable to the corresponding MCDLP security policy, wherein the one or more roles identified by the second policy condition are compared to the role data corresponding to the at least one end-user [par. 0027, if the IP address is “normal” for the user's role, based on accumulated IP address counts for all users with the same role, can be no action, but if the user is communicating with an IP address that has not been used by anyone with that role, and the IP address is unknown, and the geo-location is outside of the organizations normal geo-locations (based on geo-locations of all IP addresses the organization uses), and the protocol is a file transfer protocol, then the “halt and hold” action is performed]; a third policy condition that identifies one or more unauthorized statuses, wherein the one or more unauthorized statuses are compared to the status data corresponding to the at least one end-user [par. 0084, A data packet can be determined to be suspicious… when a data packet cannot be correlated to an user device event or authorized system process]; a fourth policy condition that identifies one or more protected data types to be scanned according to the corresponding MCDLP security policy, wherein the at least one data asset is scanned to determine if the at least one data asset comprises the protected information corresponding to the one or more protected data types [pars. 0121-0122, the network data packet can include information about a company asset (e.g., a computer file containing confidential information). The asset can be associated with a department within the company, TICAP can detect the network data packet, generate an network security event based on the network data packet and determine an action corresponding to a network security policy]; and a fifth policy condition that includes verification criteria for confirming or denying the activity event according to the corresponding MCDLP security policy [par. 0007, “comparing the communication to the one or more network security rules and the information corresponding to the user device events in the second instance of the distributed database, determining to hold the communication based on the comparing, transmitting, to a security operations center, an indication of a network security event based on determining to hold the communication, receiving a command from the security operations center in response to the transmitting, and executing the command, where the command causes the security appliance to block or allow the communication”], wherein the verification criteria identifies one or more end-users to receive verification requests and identifies a time period for receiving the verification response from the one or more end- users [par. 0102, “the computing device can use the network security policy to determine rules on overrides. For example, to determine an order of notifications of users in the user authorization hierarchy and a time lapse before delegation of the next user in the user authorization hierarchy if no response is received”]; and wherein the security enforcement platform determines whether the activity event is authorized by the corresponding MCDLP security policy based, at least in part, on the first policy condition, the second policy condition, the third policy condition, the fourth policy condition, and the fifth policy condition [pars. 0123-0125, SOC can receive the network security event, process the network security event using the network security policy and determine an action, permit the user to authorize the network data packet (e.g., permanently or temporarily), deny the network data packet, or defer the decision to another user].
Regarding claim 5, the rejection of claim 4 is incorporated.
Janssen further discloses evaluating the first policy condition and the second policy condition to determine whether the activity event is applicable to the corresponding MCDLP security policy [par. 0025, “If the user has a role like “Human Resources” then emailing employee names in bulk might be typical behavior, but if the user has the role of “Janitor” then this behavior would not be normal” (consider first policy and second policy)]; and in response to determining that the activity event is applicable to the corresponding MCDLP security policy, evaluating the third policy condition, the fourth policy condition, and the fifth policy condition to determine if the activity event is authorized or unauthorized under the corresponding MCDLP security policy [par. 0007, “comparing the communication to the one or more network security rules and the information corresponding to the user device events in the second instance of the distributed database, determining to hold the communication based on the comparing, transmitting, to a security operations center, an indication of a network security event based on determining to hold the communication, receiving a command from the security operations center in response to the transmitting, and executing the command, where the command causes the security appliance to block or allow the communication”, par. 0027, “the data loss prevention rule, such as in example 330 and 340 in FIG. 3, if the IP address is “normal” for the user's role, based on accumulated IP address counts for all users with the same role, can be no action, but if the user is communicating with an IP address that has not been used by anyone with that role, and the IP address is unknown, and the geo-location is outside of the organizations normal geo-locations (based on geo-locations of all IP addresses the organization uses), and the protocol is a file transfer protocol, then the “halt and hold” action is performed” (evaluating third and fourth policies after first and second policies)].
Regarding claim 6, the rejection of claim 1 is incorporated.
Janssen further discloses determining whether the activity event is compliant with the one or more MCDLP security policies further includes: comparing the status data corresponding to the at least one end-user with at least one policy condition set forth in the one or more MCDLP security policies [par. 0024, users can be required to log in to a user device, and the login information provided by the user can be used to determine the user identifier for that user. Accordingly, the user identifier can be associated with user device events that occur while the user is logged in to the user device], and determining that the activity event is not compliant with the one or more MCDLP security policies if the status data does not satisfy the at least one policy condition [par. 0084, A data packet can be determined to be suspicious… when a data packet cannot be correlated to an user device event or authorized system process]; and determining that the activity event is not compliant with the one or more MCDLP security policies in response to the verification response not being received within a predetermined time period or in response to the verification response include a denial message [par. 0102, “the computing device can use the network security policy to determine rules on overrides. For example, to determine an order of notifications of users in the user authorization hierarchy and a time lapse before delegation of the next user in the user authorization hierarchy if no response is received”, par. 0037, notify the user of network security events and allow the user to authorize, deny, defer, via a process described below, and/or further analyze communications associated with the network security events ].
Regarding claim 7, the rejection of claim 1 is incorporated.
Janssen further discloses determining whether the activity event is compliant with the one or more MCDLP security policies includes: determining, by the security evaluation platform, whether the one or more MCDLP security policies apply to the activity event based, at least in part, on a comparison of the role data corresponding to the to at least one end-user with at least one policy condition set forth in the one or more MCDLP policies [par. 0025, If the user has a role like “Human Resources” then emailing employee names in bulk might be typical behavior, but if the user has the role of “Janitor” then this behavior would not be normal]; in response to determining that the one or more MCDLP security policies apply to the activity event, determining, by the security evaluation platform, that the activity event is not compliant with the one or more MCDLP security policies in response to: a) detecting that the at least one data asset comprises the protected information based on said scanning [pars. 0121-0122, the network data packet can include information about a company asset (e.g., a computer file containing confidential information). The asset can be associated with a department within the company, TICAP can detect the network data packet, generate an network security event based on the network data packet and determine an action corresponding to a network security policy ]; and b) detecting at least one of following conditions: i) the status data corresponding to the at least one end-user associated with the activity event corresponds to an unauthorized status specified by a policy condition set forth in the one or more MCDLP security policies [par. 0084, A data packet can be determined to be suspicious… when a data packet cannot be correlated to an user device event or authorized system process]; ii) the verification response is not received within a predetermined time period specified by a policy condition set forth in the one or more MCDLP security policies [par. 0102, “the computing device can use the network security policy to determine rules on overrides. For example, to determine an order of notifications of users in the user authorization hierarchy and a time lapse before delegation of the next user in the user authorization hierarchy if no response is received”]; or iii) the verification response is received and denies the activity event [par. 0037, notify the user of network security events and allow the user to authorize, deny, defer, via a process described below, and/or further analyze communications associated with the network security events].
Regarding claim 9, the rejection of claim 1 is incorporated.
Janssen further discloses wherein the activity event corresponding to at least one data asset is generated in response to a first end-user sharing, or attempting to share, the at least one data asset with a second end-user [par. 0025, If the user has a role like “Human Resources” then emailing employee names in bulk might be typical behavior, but if the user has the role of “Janitor” then this behavior would not be normal], and executing the one or more remediation functions includes at least one of: revoking sharing privileges or access privileges granted to the second end-user; preventing the at least one data asset from being shared with the second end-user; encrypting the at least one data asset; or quarantining the at least one data asset [par. 0026, a data loss prevention rule that triggers a “halt and hold” action, par. 0059, data encryption controls (e.g. file encryption and/or secure tunnels)… quarantined email controls].
the security enforcement platform operates as a centralized controller that remotely communicates with one or more SaaS platforms to enforce the one or more MCDLP security policies on data assets stored by the one or more SaaS platforms.
Regarding claim 10, the rejection of claim 1 is incorporated.
Janssen further discloses the security enforcement platform operates as a centralized controller that remotely communicates with one or more platforms to enforce the one or more MCDLP security policies on data assets stored by the one or more platforms [par. 0043, “TICAP 140 can monitor the instance of the database, determine that a suspicious set of user device events or communications occurred (e.g., an unusual network communication from a first device followed by an unusual network communication from a second device, abnormal user behavior, etc.), send information corresponding to the suspicious set of user device events or communications to SOC 150, and/or determine to block or allow a communication based on the suspicious set of user device events or communications”].
Chapman further disclose the security enforcement platform operates as a centralized controller that remotely communicates with one or more SaaS platforms to enforce the one or more security policies on data assets stored by the one or more SaaS platforms [par. 0017, the appliance is configured to communicate with an exterior platform such as, for example, a software as a service platform... The appliance gathers identifying information and/or contact information, e.g., e-mail addresses, telephone numbers, mobile telephone numbers, social media identifiers, such as FACEBOOOK account IDs, TWITTER user names, etc., for example, of employees of the organization, such as from directories, databases, management systems, messaging systems, and incident response systems of the organization].
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to incorporate the teaching of Chapman into the teaching of Janssen with the motivation of reducing organizational susceptibility to social engineering as taught by Chapman [Chapman: par. 0005].
Regarding claim 11, it recites limitations like claim 1. The reason for the rejection of claim 1 is incorporated herein.
Regarding claim 12, it recites limitations like claim 2. The reason for the rejection of claim 2 is incorporated herein.
Regarding claim 13, it recites limitations like claim 3. The reason for the rejection of claim 3 is incorporated herein.
Regarding claim 14, it recites limitations like claim 4. The reason for the rejection of claim 4 is incorporated herein.
Regarding claim 15, it recites limitations like claim 5. The reason for the rejection of claim 5 is incorporated herein.
Regarding claim 16, it recites limitations like claim 6. The reason for the rejection of claim 6 is incorporated herein.
Regarding claim 17, it recites limitations like claim 7. The reason for the rejection of claim 7 is incorporated herein.
Regarding claim 19, it recites limitations like claim 9. The reason for the rejection of claim 9 is incorporated herein.
Regarding claim 20, it recites limitations like claim 10. The reason for the rejection of claim 10 is incorporated herein.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Janssen (US 2016/0127417 A1) and Chapman (US 2016/0234245 A1) as applied to claims 1-7, 9-17 and 19-20 above, and further in view of McMahon (US 2007/0233531 A1).
Regarding claim 8, the rejection of claim 1 is incorporated.
Chapman disclose the security enforcement platform communicates with an identify management system (IMS) to obtain data corresponding to at least one end-user [par. 0020, The sources 106 may include directories 108, such as, for example, employee contact information directories, ACTIVE DIRECTORY available from MICROSOFT, Lightweight Directory Access Protocol (LDAP) directories, OpenLDAP directories, as well as alternative identity management services including federated id systems, etc].
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to incorporate the teaching of Chapman into the teaching of Janssen with the motivation of reducing organizational susceptibility to social engineering as taught by Chapman [Chapman: par. 0005].
They do not explicitly disclose communicates with an identify management system (IMS) to obtain the role data corresponding to at least one end-user and the security enforcement platform communicates with a human resource information system (HRIS) to obtain the status data corresponding to at least one end-user.
However, McMahon teaches communicates with an identify management system (IMS) to obtain the role data corresponding to at least one end-user [par. 0055, characteristics of a responsive identity management system may include support for role-based provisioning for most critical systems and applications] and the security enforcement platform communicates with a human resource information system (HRIS) to obtain the status data corresponding to at least one end-user [par. 0085, “Security Manager 512 manually obtains a list of current contractors. At step 580, Human Resources Department 503 automatically generates a list of employees from the human resources system”, claim 7, the status change for the system user comprises a change in employment status].
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to incorporate the teaching of McMahon into the teaching of Janssen and Chapman with the motivation for implementing an identity management system for an organization as taught by McMahon [McMahon: par. 0003].
Regarding claim 18, it recites limitations like claim 8. The reason for the rejection of claim 8 is incorporated herein.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicant’s disclosure:
US 12238177 B1 Mid-link Forensic System For Remote Application Environment
US 20200162431 A1 Zero Trust And Zero Knowledge Application Access System
US 20170372070 A1 CLOUD STORAGE SCANNER
US 20170264640 A1 SYSTEMS AND METHODS OF ENFORCING MULTI-PART POLICIES ON DATA-DEFICIENT TRANSACTIONS OF CLOUD COMPUTING SERVICES
US 20140173739 A1 AUTOMATED ASSET CRITICALITY ASSESSMENT
US 20070136603 A1 Method And Apparatus For Providing Secure Access Control For Protected Information
US 20250211621 A1 CLOUD SERVICE SECURITY RISK ASSESSMENT AND MANAGEMENT
US 20240259416 A1 ADAPTIVE PROTECTION MECHANISMS LOOP
US 20180027006 A1 SYSTEM AND METHOD FOR SECURING AN ENTERPRISE COMPUTING ENVIRONMENT
US 20230252147 A1 SYSTEM AND METHOD FOR CLOUD-BASED OPERATING SYSTEM EVENT AND DATA ACCESS MONITORING
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON CHIANG whose telephone number is (571)270-3393. The examiner can normally be reached on 9 AM to 6 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571) 272-2092. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JASON CHIANG/Primary Examiner, Art Unit 2431