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 .
Response to Amendments
This final office action is in response to the amendments filed 12/22/2025. In
which, claims 1, 16, and 17 have been amended, no claims have been cancelled, and claims 1-20 remain pending in the application.
Response to Amendment
The amendment filed on 12/22/2025 has been entered. See response to
amendments.
Response to Arguments
Applicant’s amendments and arguments are fully considered and are
persuasive however arguments are moot in view of new ground of
rejection below.
With respect to applicant’s argument to the remaining dependent claims 2-15, and 18-20 of the remark, the applicant is relying on the newly added amendments of the independent claims 1, 16, and 17. Please see Examiner’s response above and the detail of 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, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 8, 9, 16, and 17 are rejected under 35 U.S.C. 103 as unpatentable over by Kass et al. (US-20130054509-A1 hereafter Kass), in view of Ganesh et al. (US-10296520-B1 hereafter Ganesh), in further view of Sakamoto et al. (US-20050203881-A1 hereafter Sakamoto).
Regarding claim 1 Kass discloses an apparatus for performing access threat detection for a collaborative software application framework (see Kass par.0014: “The architecture 100 includes an extended collaboration event monitoring system 102, a social network system 104, a social network adapter 106, and user portals 108, each of which is configured to communicate over a communications network 110. The user portals 108 may correspond to members of a project team or collaboration group using client applications, or other computer software applications, to perform a business process or plan. The computer software applications corresponding to the user portals 108 may be extended via a software addin to monitor a user's actions within the application and identify relevant events occurring within those client applications. As an example, the client application may be an office suite application, e.g., Microsoft Office.RTM., WordPerfect Office.RTM., etc., or other computer software applications.”), the apparatus comprising at least one processor and at least one memory including program code, the at least one memory and the program code configured to, with the at least one processor, cause the apparatus to at least (see Kass par.0017: “The system 102 includes an event repository 112, which includes an event database. The system 102 also includes an inference engine 114 and a semantic bus 116. The various components of the system 102 may be stored in a memory and performed by a computer processor, or may be distributed over multiple memory structures and performed by multiple computer processors that are locally connected or connected across the communications network 110.”):
access event data associated with the collaborative software application framework wherein the collaborative software application framework comprises a collaborative work platform configured to enable a plurality of client computing devices to simultaneously access one or more collaborative documents (see Kass par.0025: “a process 200 by which an extended collaboration event monitoring system, such as the system 102, identifies and extracts events and published events to a collaboration interface embedded into a computer software application. The system 102 monitors a user's interactions with a computer software application, such as a client application, for an event performed by the user (Block 202). The system 102 may include a software addin that monitor's the user's actions. The user may be a member of a project team or collaboration group, the members of which may be located remotely relative to each other and may be using different applications at any given time. An event may be an act taken by the user in the application, such as completing a document or a section of a document, completing review of a document, mentioning a relevant keyword or individual in a document, or other events that may be relevant to the other members of the project team or collaboration group.”);
Kass appear to be silence however Ganesh teaches
identify at least one threat event record object based on the event data, wherein the at least one threat event record object describes an access pattern associated with an entity, and wherein the access pattern is associated with an access to at least one collaborative document of the collaborative software application framework by the entity (see Ganesh Col.10 lines 50-60: “identifying collaborative activity with multiple users accessing certain files (one collaborative document) or folders may be identified as anomalous or unauthorized file access activity. For example, certain folders (e.g., a home directory or home folder) may be intended to only be accessible by a single user. However, if the collaboration information identifies that two users have accessed the same home folder, then such activity may be identified as anomalous or unauthorized behavior. An alert may be issued to a network administrator to address the file permissions for the user with the anomalous behavior.”);
determine, via at least one threat detection policy employed by a threat detection model, that the access pattern associated with the at least one threat event record object satisfies at least one access threshold parameter (see Ganesh Col.8 lines 61-67 -Col.9 lines 1-23: “the clusters 510 and 520 may include multiple user nodes representing multiple users. For example, the cluster 510 may include ten user nodes representing ten highly collaborative users that are connected with high weight value links. As an example, the cluster 510 may represent an engineering group within a corporate enterprise. The ten users corresponding to the ten user nodes of the cluster 510 may be connected with high weight value links (one access threshold parameter) as the ten users are each editing, reading, or performing other file access actions on the same or similar engineering files on a network file system… the cluster 530 may only include a single user node corresponding to a single user. However, the user node within the cluster 530 may be accessing one or more files that users from the cluster 510 are accessing. For example, links 531, 532, and 533 may represent that the user from the cluster 530 is accessing files that multiple users from the cluster 510 are accessing (one threat detection policy). Such activity may represent anomalous or unauthorized file access behavior (the access pattern)or unauthorized collaborative behavior as the user in the cluster 530 is not part of the cluster 510, but is accessing the same or similar files that users of the cluster 530 are accessing. Such behavior may indicate that the user in the cluster 530 may be a malicious insider within the corporate organization who is performing unauthorized file accesses.”); and
in response to determining that the access pattern associated with the at least one threat event record object satisfies the at least one access threshold parameter (see Ganesh Col.10 lines 50-60: “identifying collaborative activity with multiple users accessing certain files or folders may be identified as anomalous or unauthorized file access activity. For example, certain folders (e.g., a home directory or home folder) may be intended to only be accessible by a single user. However, if the collaboration information identifies that two users have accessed the same home folder, then such activity may be identified as anomalous or unauthorized behavior. An alert may be issued to a network administrator to address the file permissions for the user with the anomalous behavior.”):
generate, based on the at least one threat detection policy employed by the threat detection model, at least one access threat alert associated with the collaborative software application framework (see Ganesh Col.10 lines 50-60: “identifying collaborative activity with multiple users accessing certain files or folders may be identified as anomalous or unauthorized file access activity. For example, certain folders (e.g., a home directory or home folder) may be intended to only be accessible by a single user. However, if the collaboration information identifies that two users have accessed the same home folder, then such activity may be identified as anomalous or unauthorized behavior. An alert may be issued to a network administrator to address the file permissions for the user with the anomalous behavior.”); and
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Kass teaching “the extended collaboration event monitoring system 102 provides team members with a meaningful log of each other's activities to help improve awareness and coordination. The system 102 not only notifies team members of which files each other is working with, but provides a more fine-grained awareness of what they are doing within the file, what topics and entities they are discussing or focusing on, and other relevant information.”, (see Kass par.0042) with Ganesh teaching “the analyzer module 200 may include a log file data sub-module 210. In some embodiments, the log file data sub-module 210 may record information associated with users accessing files stored in the network file system. For example, the log file data sub-module 210 may receive a stream of file accesses and create a log file or update a log file to include recent file accesses. In some embodiments, the log file may include an entry for each instance of a user accessing a file on the network file share. For example, an entry may be created each time that a user has accessed a single file. The entry may identify the user, the file that was accessed, the location of the file, the type of action that the user performed on the file (e.g., opened or read the file, edited or wrote to the file, copied the file, deleted the file, etc.), and/or the time when the user accessed the file.”, (see Ganesh Col.4 lines 30-45).
Kass in view of Ganesh do not explicitly teach however Sakamoto teaches
cause display of the at least one access threat alert via an interactive threat detection dashboard rendered on a client computing device associated with the collaborative software application framework. (See Fig 6F and 6M, par.0089: “FIGS. 6A-6M. In one embodiment, configuring a monitoring operation is performed with a graphical user interface implemented using a web browser. In the example user interface screens depicted by FIGS. 6A-6M, users can follow the previous/next navigation arrows to step through the process of configuring a monitoring operation. Alternatively, users may select an item from the menu bar on the top panel, or click a link from the hierarchical tree view on the left panel.”, par.0096: “The user generates summary reports on the alerts, which can help analyze the problems, as shown in FIG. 6M.”
PNG
media_image1.png
529
705
media_image1.png
Greyscale
PNG
media_image2.png
527
731
media_image2.png
Greyscale
).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Kass in view of Ganesh teaching described above with Sakamoto teaching “The security rules 92 provide a mechanism for enabling the anomaly detector 116 to determine if a breach of security may have occurred. The administrator station 144 enables management of the security rules 92. Once anomalous data is identified, the anomaly detector 116 performs the targeted operation. For example, the anomaly detector 116 may send e-mail alerts 96 to signal an intrusion to the administrator station 144. The anomaly detector 116 may also or in addition provide reports 94 or create visualizations 98.”, (see Sakamoto par.0046).
Regarding claim 16 is a computer product claim that recites similar limitations as the method claim 1 and is being rejected based on the same rational as claim 1. the computer program product comprising at least one non-transitory computer-readable storage medium having computer-readable program code portions stored therein, the computer-readable program code portions configured to (see Kass par.0038: “processes, programs, and/or instructions may be encoded in a signal-bearing medium, a computer-readable medium such as a memory, programmed within a device such as on one or more integrated circuits, or processed by a controller or a computer processor. If the methods are performed by software, the software may reside in a memory resident to or interfaced to a communication interface, or any other type of non-volatile or volatile memory. The memory may include an ordered listing of executable instructions for implementing logical functions. A logical function may be implemented through digital circuitry, through source code, through analog circuitry, or through an analog source such as that occurring through an analog electrical, audio, or video signal. The software may be embodied in any computer-readable or signal-bearing medium, for use by, or in connection with, an instruction executable system, apparatus, or device.”).
Regarding claim 17 is a computer-implemented method claim that recites similar limitations as the method claim 1 and is being rejected based on the same rational as claim 1.
Regarding claim 8 Kass in view of Ganesh, and Sakamoto discloses the apparatus of claim 1, Sakamoto further teaches wherein the at least one access threshold parameter is a first access threshold parameter of a plurality of access threshold parameters,
wherein the plurality of access threshold parameters comprises at least one of a view count, view duration, modification count, modification amount, export count, export amount, import count, or import amount associated with at least one portion of content data associated with the collaborative software application framework; and
wherein each access threshold parameter of the plurality of access threshold parameters is associated with a predetermined time interval.
However, Sakamoto discloses wherein the at least one access threshold parameter is a first access threshold parameter of a plurality of access threshold parameters (see Sakamoto par.0075: “a high level overview of anomaly detection processing in one embodiment. In block 351, a frequency of database access is determined from new set of data. In block 352, a threshold frequency is determined from the guard criteria and the probability function parameter. In one embodiment, the probability function parameter is the access frequency of historic data, determined previously by the data analyzer in block 331. In one embodiment, the access frequency is the average number of SELECT operations by the hour of day.”, par.0085: “the following access violation rules can be specified for object level monitoring: (1) object access security violation, in which any failed attempt to read specific object without proper permission is alerted; (2) object access by suspicious OS user, in which any successful read of specific object by invalid OS users is alerted.” Examiner interpret that the violation rulers are the plurality of access threshold parameters.),
wherein the plurality of access threshold parameters comprises at least one of a view count, view duration, modification count, modification amount, export count, export amount, import count, or import amount associated with at least one portion of content data associated with the collaborative software application framework (see Sakamoto par.0060: “database session level monitoring includes monitoring a database connection or a login session by a selected database user. Database monitoring will track login duration, login failure and resource utilization by this user.”, par.0073: “In addition to object or user access frequency, other measurements can be used for session level monitoring in various embodiments, such as without limitation, access frequency by session measured by a number of page reads per session, access duration by session measured by a number of hours per session, and access ratio measured by a number of page reads per minute.”); and
wherein each access threshold parameter of the plurality of access threshold parameters is associated with a predetermined time interval. (See Sakamoto par.0078-81: “if the guard probability criteria is specified as 0.1 %, the anomaly detector calculates the threshold value n such that the probability of having a value exceeding n is less than 0.1 % as shown in equation (3), This is equivalent to determining the threshold value n such that the probability of having a value less or
equal ton is more than 99.9% as shown in equation (4), Substituting the cumulative distribution function in equation (2) with F(n)>99.9% from equation (4), and m of value 1.5 (probability function parameter, the average access frequency of historic data), results in a threshold value for n of 6. Since the access frequency of new data set is 7,
which exceeds the threshold access frequency value 6, an anomaly will be detected.”.) Examiner interpret that the predetermined time interval can be calculated by the four equation mention above.).
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Kass in view of Ganesh, and Sakamoto teaching of claim 1 with Sakamoto teaching “database object level monitoring includes monitoring database accesses for a selected critical or sensitive database object. A database object can be a database table, database view, or database stored procedure. Database monitoring will track who, when, where and how often this object is accessed by any user. An example of a critical database object is a company's "employee" table, which contains salary information of the employees.”, (see Sakamoto par.0058).
Regarding claim 9 Kass in view of Ganesh, and Sakamoto discloses the apparatus of claim 1, Ganesh further teaches wherein the at least one access threat alert is associated with at least one of an alert severity, an alert identifier, an access threat alert type, an alert description, an alert data source, an alert timestamp, an alert responder profile, an alert mitigation status, or an alert mitigation ticket. (See Ganesh Col.10 lines 50-60: “identifying collaborative activity with multiple users accessing certain files or folders may be identified as anomalous or unauthorized file access activity. For example, certain folders (e.g., a home directory or home folder) may be intended to only be accessible by a single user. However, if the collaboration information identifies that two users have accessed the same home folder, then such activity may be identified as anomalous or unauthorized behavior. An alert may be issued to a network administrator to address the file permissions for the user with the anomalous behavior.”).
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Kass in view of Ganesh, and Sakamoto teaching of claim 1 with Ganesh teaching “the identification of a user node with attributes different than other user nodes within the same cluster may be highlighted or identified and displayed (e.g., by the console sub-module 250). For example, if most of the user nodes in a cluster have an engineering group user attribute and one of the user nodes has a marketing group user attribute, the user node with the marketing group user attribute may be highlighted and identified as a potential anomalous activity.”, (see Ganesh Col.10 lines 41-49).
Claims 2, 4-6, 10-13, 15, 18, and 20 are rejected under 35 U.S.C. 103 as unpatentable over by Kass et al. (US-20130054509-A1 hereafter Kass), in view of Ganesh et al. (US-10296520-B1 hereafter Ganesh), in view of Sakamoto et al. (US-20050203881-A1 hereafter Sakamoto), in further view of Muddu et al. (US-20170134415-A1 hereafter Muddu).
Regarding claim 2 Kass in view of Ganesh, and Sakamoto discloses the apparatus of claim 1, Kass in view of Ganesh, and Sakamoto do not explicitly teach however Muddu teaches wherein the at least one threat detection policy is a first threat detection policy of a plurality of threat detection policies associated with the threat detection model (see Muddu par.403: “Process 3400 continues at step 3406 with comparing the subset of the threat indicator data against preconfigured patterns or pre-set rules associated with each candidate threat. For example, an insider threat may be associated with known patterns identified by security experts and therefore be associated with pre-set rules.”, par.435: “At step 3880, as an optional step, the process confirms that the anomalies form a security threat by applying a security rule to the anomalies based on assigned categories of the anomalies. The computer system can assign the anomalies into categories of, e.g., internal anomaly, malware anomaly, incoming anomaly and exfiltration anomaly.”),
wherein the plurality of threat detection policies is associated with a plurality of clients (see Muddu par.481: “FIG. 45A, the Threats listing 4520 lists all active threats. The Threats listing provides, for each entry, the Threat Type 4530, Participants 4531, Event Date 4532, Last Update 4533, and Score 4534. A summary section 4535 identifies the number of threats of each type and provides an option to just display the threats of a certain specified type.”, par.447: “Like an anomaly, a threat can be associated with one or more participants, including users, devices, and applications.”).
PNG
media_image3.png
903
1256
media_image3.png
Greyscale
, wherein the plurality of clients is associated with a plurality of collaborative software application frameworks (see Muddu par.447: “Like an anomaly, a threat can be associated with one or more participants, including users, devices, and applications(a plurality of collaborative software application).”), and
wherein each threat detection policy of the plurality of threat detection policies is associated with one or more respective access threshold parameters. (See Muddu par.359-361: “Process 2500 continues at step 2504 with processing the event data 2302 through an anomaly model. According to an embodiment, an anomaly model includes at least model processing logic defining a process for assigning an anomaly score to the event data 2302 and a model state defining a set of parameters for applying the model processing logic…Process 2500 continues at step 2504 with processing the event data 2302 through an anomaly model. Each of these anomaly models would include unique processing logic and parameters for applying the processing logic. Similarly, each model instance (i.e. for a particular entity)
may include unique processing logic and parameters for applying the processing logic. Process 2500 continues at step 2506 with assigning an anomaly score based on the processing of the event data 2302 through the anomaly model. Calculation of the
anomaly score is done by the processing logic contained within the anomaly model and represents a quantification of a degree to which the processed event data is associated with anomalous activity on the network. Process 2500 continues at step 2508 with outputting an indicator of a particular anomaly if the anomaly score satisfies a specified criterion ( e.g., exceeds a threshold).”).
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Kass in view of Ganesh, and Sakamoto teaching of claim 1 with Muddu teaching “Process 3400 concludes at step 3410 with identifying a security threat if the pattern matching score satisfies a specified criterion. Continuing with the given example, the specified criterion may be set such that an threat is identified if the pattern matching score is 6 or above. The specified criterion need not be static, however. In some embodiments, the criterion is dynamic and changes based on situational factors. Situational factors may include volume of event data, presence or absence of pre-conditional events, user configurations, volume of detected anomalies, and involvement of mission critical systems.”, (see Muddu par.404).
Regarding claim 18 is a computer-implemented method claim that recites similar limitations as the method claim 2 and is being rejected based on the same rational as claim 2.
Regarding claim 4 Kass in view of Ganesh, Sakamoto and Muddu disclose the apparatus of claim 2, Muddu further discloses wherein the at least one threat event record object is a first threat event record object of a batch of threat event record objects, (see Muddu par.161: “The event data from the ETL block 204 is also provided to a batch analyzer 240 over a batch processing path 242 for detecting anomalies, threat indicators and threats. However, while the event data is provided to the real-time analyzer 210 in an unbounded, streaming, record by-record manner, it is provided to the batch analyzer in the form of batches of event data (i.e., where each batch of event data contains a collection of events that arrived over the batch period).”),
wherein the batch of threat event record objects is associated with the plurality of collaborative software application frameworks (see Muddu par.337: “Among other reasons, the big-data based, highly modularized characteristics of the security platform architecture introduced here present many opportunities for different
components to benefit from intelligence sharing. For example, in certain implementations, as mentioned above, the security platform can include at least two event processing engines----one event processing engine operating in a real-time mode to process unbounded, streaming data that enters the security platform, and the other event processing engine operating in a batch mode to process batches of historical event data. In another example, a security platform deployed in an environment (e.g., an organization or an enterprise) may communicate with another security platform deployed in a different environment. All these event processing engines, because of their different operating modes, different data input, and/or different deployed environment, can potentially benefit from the knowledge gained by each another.”. [0186] “anomalies and threats are detected by comparing incoming event data (e.g., a series of events) against the baseline profile for an entity to which the event data relates (e.g., a user, an application, a network node or group of nodes, a software system, data files, etc.).”), and
wherein the threat detection model is applied to the batch of threat event record objects. (See Muddu par.285: “the content of the distributed file system 1514 can be shared with another distributed computation system ( e.g., a batch data processing engine discussed in various parts of this disclosure). For example,
a model state stored in the model store 1532 representing a machine learning model or a version of a machine learning model can be shared with the other distributed computation system.” Further in [0186].).
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Kass in view of Ganesh, Sakamoto and Muddu teaching of claim 2 with Muddu teaching “he security platform 300 can create a behavior baseline for any type of entity (for example, a user, a group of users, a device, a group of devices, an application, and/or a group of applications). In the example of FIG. 6, the activities of server 606 are monitored and a baseline profile 616 specific for the server 606 is generated over time, based on event data indicative of network activities of server 606. Baseline profiles can be continuously updated (whether in real-time as event data streams in, or in batch according to a predefined schedule) in response to received event data, i.e., they can be updated dynamically and/or adaptively based on event data. If the human user 604 begins to access source code server 610 more frequently in support of his work, for example, and his accessing of source code server 610 has been judged to be legitimate by the security platform 300 or a network security administrator (i.e., the anomalies/threats detected upon behavior change have been resolved and deemed to be legitimate activities), his baseline profile 614 is updated to reflect the updated “normal” behavior for the human user 604.”, (see Muddu par.0184-0185).
Regarding claim 20 is a computer-implemented method claim that recites similar limitations as the method claim 4 and is being rejected based on the same rational as claim 4.
Regarding claim 5 Kass in view of Ganesh, and Sakamoto discloses the apparatus of claim 1, Sakamoto further teaches generate, via the threat detection data service and based at least in part on one or more database commands initiated by the threat detection job service, the at least one threat event record object based on the event data associated with the one or more dynamic table objects (see Sakamoto par.0042: “The data collector 112 is configured to read data about user behavior relating to accessing the database 132 from the database server 130 at designated intervals, or upon the occurrence of designated conditions (such as manual commands) and to store the data as historical data. The database analyzer 114 performs analysis operations on the historical data stored by the data collector 112 to determine behavior patterns relating to accessing the database 132. When new data is received, the anomaly detector 116 determines, based upon a comparison of new data with a behavioral pattern determined from historical data, whether the new data represents anomalous activity.”, par.0043: “the data collector also obtains dynamic performance views 86 comprising information on database usage, such as user sessions and resource utilization that is maintained by the database management
system (DBMS). The data collector 112 stores the user behavior data obtained from the audit trail 84 and dynamic performance views 86 as historical data 88.”, par.0052: “The
dynamic system view provides information on current user sessions and resource utilization. For example, one popular database management system provides several dynamic performance views which are security relevant, V $SESSION lists information for each current user session, $SESS IO lists I/0 statistics for each user session,
V_$SESS IO lists 1/0 statistics for each user session,= $S ESSTAT lists user session statistics, V $ACCESS shows objects that are currently locked and the sessions that
are accessing them and V $SQL shows the SQL command text in the SQL pool.”. Examiner interpret that data analyzer 114 (Threat detection data service) and based at least in part on one or more database command initiated by the anomaly detector 116 (the threat detection job service) generate the at least one threat event record object (historical data 88) based on the database management system dynamic performance views of the one or more dynamic table object(database), wherein the one or more database commands are initiated based at least in part on the at least one access threat detection job. (See Sakamoto par.0056: “The data collector collects user behavior data from audit trail or dynamic performance views, processes the information, and stores the data as historical data. The historical data can be saved in an internal database for example. In one embodiment, a variety of attributes are recorded in the historical data for each action of interest. For example, a SELECT or a LOGIN action will include attributes such as, without limitation: (1) an operating system user identifier (OSUSER); (2) a database user identifier of the user who performs the action (DEUSER); (3) a subject schema object identifier (OBJECT); ( 4) owner of the object (OWNER); (5) a client system identifier (LOCATION); (6) an action identifier (ACTION); (7) a time of action (TIMESTAMP); (8) number of logical reads for the session (READ); (9) number of logical writes for the session (WRITE); and (10) a success or failure reason code (RETURNCODE).”. Examiner interpret that the data collector (access threat detection job) can initiate the above describe database commands).
Kass in view of Ganesh, and Sakamoto do not explicitly teach however Muddu teaches wherein the program code is configured to, with the at least one processor, further cause the apparatus to (see Muddu par.742: “Processor(s) 8510 and adapters 8540 and 8550 may, in turn, include processing elements and/or logic circuitry configured to execute the software code and manipulate the data structures. It will be apparent to those skilled in the art that other processing and memory implementations, including various machine-readable storage media, may be used for storing and executing program instructions pertaining to the techniques introduced here.”):
generate, via a threat detection data service and based at least in part on at least one access threat detection job initiated by a threat detection job service, one or more dynamic table objects (see Muddu par.164-172: “The data sources 302 provide event data to data receivers 310, which implement various APis and connectors to receive ( or retrieve, depending on the mechanism) the event data for the security platform 300… The received data is then provided via a channel 314 to a semantic processor (or data preparation stage) 316, which in certain embodiments performs, among other functions, ETL functions. In particular, the semantic processor 316 may perform parsing of the incoming event data, enrichment (also called decoration or annotation) of the event data with certain information, and optionally, filtering the event data. The semantic processor 316 introduced here is particularly useful when data received from the various data sources through data receiver 310 is in different formats, in which case the semantic processor 316 can prepare the data for more efficient downstream utilization (including, for example, by an event processing engine) while avoiding binding the unstructured data into any particular type of data structure. A parser in the semantic processor 316 may parse the various fields of received event data representing an event (e.g., a record related to a log-in event). An identity resolution (IR) component may be optionally provided within the semantic processor 316 to correlate IP addresses with users,… Data processed by the semantic processor 316 is sent to a distribution block 320. The real-time processing path includes an analysis module 330 that receives data from the distribution block 320. The analysis module 330 analyzes the data in real-time to detect anomalies, threat indicators, and threats…. The event data that underlies those notifications or that gives rise to the detection made by the analysis module 330 are persistently stored in a database 378… The rejection of the analysis result may also be provided to the database 378…. Arrow 360 represents the storing of data supporting the analysis of the anomalies and threats in the real-time path. For example, the anomalies and threats as well as the event data that gives rise to detection of the anomalies and threats may be stored in database 378 (e.g., an SQL store) using a path represented by the arrow 360. Additional information such as the version of the models, the identification of the models used, and the time that the detection is made, may also be stored.”). Examiner interpret that based on the data source provide to the data receivers 310 (threat detection data service) in part with the semantic processor 316 (access threat detection job) initiated by threat detection job service (analysis module 330) generate a dynamic table objects (Database 378), wherein the one or more dynamic table objects generated based at least in part on metadata associated with the event data (see Muddu par.172: “the anomalies and threats as well as the event data that gives rise to detection of the anomalies and threats may be stored in database 378 (e.g., an SQL store) using a path represented by the arrow 360. Additional information such as the version of the models, the identification of the models used, and the time that the detection is made, may also be stored.”).
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Kass in view of Ganesh, and Sakamoto teaching of claim 1 with Sakamoto teaching “User behavior information relative to a subject database being monitored may be automatically collected, analyzed and compared with a statistically derived norm and/or one or more policies to detect anomalous activity. collect user behavior data regarding the subject database from a variety of sources, including audit trails and dynamic views in cooperation with the database management system of the database. Embodiments employ one or more of statistics-based intrusion detection (SEID) and rule-based intrusion detection (REID) to detect anomalous database activity” (see Sakamoto par.006), along with Muddu teaching "a data processing and analytics system (and, as a particular example, a security platform) that employs a variety of techniques and mechanisms for anomalous activity detection in a networked environment in ways that are more insightful and scalable than the conventional techniques. As is described in more detail below, the security platform is "big data" driven and employs a number of machine learning mechanisms to perform security analytics. More specifically, the security platform introduced here can perform user behavioral analytics (UBA), or more generally user/entity behavioral analytics (UEBA), to detect the security related anomalies and threats, regardless of whether such anomalies and threats are previously known or unknown. Additionally, by presenting analytical results scored with risk ratings and supporting evidence, the security platform can enable network security administrators or analysts to respond to a detected anomaly or threat, and to take action promptly.", (see Muddu par.137).
Regarding claim 6 Kass in view of Ganesh, and Sakamoto disclose the apparatus of claim 5, Kass in view of Ganesh, and Sakamoto do not explicitly teach however Muddu teaches wherein the threat detection job service is configured to initiate the at least one access threat detection job based on a predefined periodicity of time. (See Muddu par.164: “The data sources 302 provide event data to data receivers 310 (threat detection service), which implement various APis and connectors to receive ( or retrieve, depending on the mechanism) the event data for the security platform 300”, par.166 “A parser in the semantic processor 316 may parse the various fields of received event data representing an event (e.g., a record related to a log-in event).”, par.167-168: ” An optional filter attribution block 322 in the semantic processor 316 removes certain pre-defined events... Data processed by the semantic processor 316 is sent to a distribution block 320.”). Examiner interpret that the receiver 310 and (threat detection job service) initiate the semantic processor 116 (threat detection service) that will facilitate the process of the detecting the potential threat recorded to log event. Par.0371: “the use case described in FIG. 27 involves a process that begins with determining a measure ( e.g., a count) of entities of the computer network associated with a particular anomaly, a particular category of anomaly, or a set of anomalies with substantially matching profiles or footprints. In some embodiments, this determination is based on an absolute number tracked from when monitoring of the computer network commenced. In other embodiments, this determination may be over a pre-determined and/or dynamic time period.” Further in [0380-0382].). Examiner interpret that the process involves in to determine a measure of a particular anomaly that may be over a pre-determined and dynamic time period as the periodicity time.
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Kass in view of Ganesh, and Sakamoto teaching of claim 5 with Muddu teaching “the anomaly data 2404 includes data in addition to the underlying event data 2302. For example, the anomaly data associated with a particular entity may include the underlying event data associated with the anomalous activity, annotated information about that entity (e.g. a user ID or account associated with a device), timing data associated with the anomalous activity (e.g. when the anomaly occurred, when a similar anomaly last occurred, or periodicity of this type of anomaly showing up for the particular entity), etc.”, (see Muddu par.0352).
Regarding claim 10 Kass in view of Ganesh, and Sakamoto discloses the apparatus of claim 1, Kass in view of Ganesh, and Sakamoto do not explicitly teach however Muddu teaches wherein the at least one access threat alert is associated with a respective access threat alert type of a plurality of access threat alert types (see Muddu par.454: “The example home screen view 3900 also prompts a user, via status bar 3911, to begin a "Threat Review" or view an "Analytics Dashboard." Upon clicking, via the graphical user interface, on the "Start Threat Review" button 3915, a "Threats Review" view 4000 is provided, as described with reference to FIG. 40A.”, par.456: “The view 4000 can include a filter section 4020 that enables the user to selectively filter out threat results according
to time, severity, or type.”.).
PNG
media_image4.png
574
887
media_image4.png
Greyscale
, and
wherein the plurality of access threat alert types comprise at least one of a collaborative document alert type, an issue tracking alert type, a suspicious search alert type, an administrative account alert type, or a code repository alert type. (See Muddu par.446: “Anomalies can be classified into various types. As examples, anomalies can be alarms, blacklisted applications/domains/IP addresses, domain name anomalies, excessive uploads or downloads, website attacks, land speed violations, machine generated beacons, login errors, multiple outgoing connections, unusual activity time/sequence/file access/network activity, etc.”).
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Kass in view of Ganesh, and Sakamoto teaching of claim 1 with Muddu teaching “The security platform can detect anomalies and threats produced by a user, a device, or an application, for example, regardless of whether the entity that causes the anomalies or threats is from outside or inside the organization's network. The security analytics techniques that can be adopted by the security platform include behavioral analytics that enable organizations of any size or skillset to detect and respond to unknown threats. Some specific examples that behavioral analytics can be based on include machine learning, behavior modeling, peer group analysis, classification, statistical models, and graph analysis. As introduced in more detail below, these analyses can utilize, for example, Markovian processing flows, inference and grouping processes, and risk scoring mechanisms to develop user and entity profiles in order to compare and contrast activities, which ultimately allow the platform to detect and expose anomalies and threats”, (see Muddu par.0140).
Regarding claim 11 Kass in view of Ganesh, Sakamoto, and Muddu disclose the apparatus of claim 10, Muddu further disclose wherein the collaborative document alert type is associated with at least one of an unusual page activity alert associated with a respective collaborative document, a mass page export alert associated with one or more respective collaborative documents, a restricted document access alert, an unauthorized user access alert, or an alert associated with a high volume of collaborative document content being made public. (See Muddu par.446: “Anomalies can be classified into various types. As examples, anomalies can be alarms, blacklisted applications/domains/IP addresses, domain name anomalies, excessive uploads or downloads, website attacks, land speed violations, machine generated beacons, login errors, multiple outgoing connections, unusual activity time/sequence/file access/network activity, etc.”), par. 467: the user navigates to Anomaly Details view 4300 for this selected anomaly, as shown in FIG. 43. In the example view provided in FIG. 40D, the two anomalies associated with the Exfiltration stage 4053 are both "Excessive Data Transmission" 4055. These are color-coded in red to provide an indication of their high level of severity.”).
PNG
media_image5.png
649
827
media_image5.png
Greyscale
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Kass in view of Ganesh, Sakamoto and Muddu teaching of claim 10 with Muddu teaching “, generating the plurality of feature scores includes analyzing the data transmission statistics associated with an entity (internal or external) over a time period and assigning a feature score based on the analysis, wherein the feature score is indicative of a level of confidence that the external entity is associated with a command and control infrastructure external to the computer network. For example, the ratio of bytes in to bytes out in a particular communication or set of communications may provide insight into the purpose of the communication. A higher volume of data going out to an external entity than is coming in may indicate the exfiltration data by malware within the network in response to commands from the external entity.”, (see Muddu par.0626).
Regarding claim 12 Kass in view of Ganesh, Sakamoto, and Muddu disclose the apparatus of claim 10, Sakamoto further teaches wherein the issue tracking alert type is associated with at least one of a mass issue tracking object export alert or unusual issue activity associated with one or more issue tracking objects. (See Sakamoto par.0085: “in various embodiments, the following access violation rules can be specified for object level monitoring: (1) object access security violation, in which any failed attempt to read specific object without proper permission is alerted; (2) object access by suspicious OS user, in which any successful read of specific object by invalid OS users is alerted.”.). Examiner interpret that the issue tracking alert type is associated with unusual issue activity associate with one or more tracking objects which is this case is the object access security of the failed attempt to read specific object and the object access by suspicious OS user.).
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Kass in view of Ganesh, Sakamoto, and Muddu teaching of claim 10 with Sakamoto teaching “intrusion detection can be statistic-based, as discussed previously, and/or rule-based. In an embodiment, guarding thresholds can be specified as an absolute value in terms of number of accesses by hour of day or the like. Access violation policies enable the database audit engine to guard each individual database access using explicit security rules.”, (see Sakamoto par.0084).
Regarding claim 13 Kass in view of Ganesh, Sakamoto, and Muddu disclose the apparatus of claim 10, Muddu further teaches wherein the administrative account alert type is associated with at least one of an administrative account change alert, an external access granted alert, a security assertion markup language (SAML) alert, an administrative account application programming interface (API) token change alert, or alert associated with a connection of an administrative account to an external third-party service. (See Muddu par. 492: “provides a second example of an Anomaly Details view, this time for a “Machine Generated Beacon” that occurred on Jul. 27, 2014 at 4:36 PM, as shown at 4655. This anomaly is associated with 4 entities: User “ggawrych” 4656, Internal Device “10.104.31.18” and External Device “46.214.107.142” 4657, and Domain “46.214.107.142” 4658. Anomaly Relations box 4659 illustrates the relationship between these entities. As can be seen, User “ggawrych” uses Internal Device “10.104.31.18” to access domain “46.214.142” operating on External Device “46.214.107.142.”).
PNG
media_image6.png
579
785
media_image6.png
Greyscale
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Kass in view of Ganesh, Sakamoto and Muddu teaching of claim 10 with Muddu teaching “Threats can be categorized or grouped into various types, both external and internal to the organization. Examples of threats include data exfiltration (by compromised account, by malware, or by a suspicious user or device), public-facing website attack, suspicious behavior by an insider, and breach of a rule (such as a blacklist, file transfers). Like an anomaly, a threat can be associated with one or more participants, including users, devices, and applications.”, (see Muddu par.0447).
Regarding claim 15 Kass in view of Ganesh, and Sakamoto discloses The apparatus of claim 1, Kass in view of Ganesh, and Sakamoto do not explicitly teach however Muddu teaches wherein the at least one access threat alert is associated with a threat detection payload, wherein the threat detection payload is associated with at least one portion of content data of the collaborative software application framework, and wherein the at least one portion of content data corresponds to an access threat alert type associated with the at least one access threat alert. (See Muddu Figure 40E:)4082
PNG
media_image7.png
900
1298
media_image7.png
Greyscale
Which is consistent with applicant instant application definition of payload, [par.136] “The threat detection payload 602 comprises data related to the titles, contents, data sources, and timestamps of the pages accessed by the entity. In various embodiments, the threat detection payload 602 may comprise one or more hyperlinks associated with the pages that were accessed by the entity.”.
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Kass in view of Ganesh, and Sakamoto teaching of claim 1 with Muddu teaching “The list of Anomalies identifies each type of anomaly that is associated with the threat and how many anomalies of each type. The list of Anomalies also provides a score for each type of anomaly, which indicates the severity associated with each type of anomaly. The list of Users identifies each user associated with the threat and provides a score for each user. Similarly, the list of Devices and list of Apps identify each device (by IP address) and App (by file name/type), respectively, along with a score.”, (see Muddu par.0458).
Claims 3 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kass et al. (US-20130054509-A1 hereafter Kass), in view of Ganesh et al. (US-10296520-B1 hereafter Ganesh), in view of Sakamoto et al. (US-20050203881-A1 hereafter Sakamoto), in view of Muddu et al. (US-20170134415-A1 hereafter Muddu), in further view of Koottayi et al. (US-11265329-B2 hereafter Koottayi).
Regarding claim 3 Kass in view of Ganesh, Sakamoto, and Muddu discloses the apparatus of claim 2, but appear to be silence on wherein the one or more respective access threshold parameters associated with the first threat detection policy are configured by a first client of the plurality of clients via the interactive threat detection dashboard.
However, Koottayi teaches wherein the one or more respective access threshold parameters associated with the first threat detection policy are configured by a first client of the plurality of clients via the interactive threat detection dashboard. (See Koottayi Col. 24 lines51-65: “The configuration of the collector 165 may be based on default or static inspection policies comprising rules for collecting a predefined set of attributes ( e.g., user attributes, resource attributes, object, actions, environment attributes, etc.) when certain criteria is satisfied. In certain embodiments, an inspection policy monitors data and informs an administrator when a certain criteria match a predefined pattern. The inspection policy does not cause an alert to be triggered when the pattern exists but collects the predefined set of attributes when the pattern exists. For example, the system may provide an inspection policy user interface (UI) that allows an administrator to designate the triggering of certain inspection policies when a set of criteria has been met ( e.g., if header data matches, for a threshold time interval).”). Examiner interpret that the administrator(s) is able to configured the threshold parameters through the user interface.
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Kass in view of Ganesh, Sakamoto and Muddu teaching of claim 2 with Koottayi teaching “In certain embodiments, the system may provide an inspection policy UI that allows an administrator to create the inspection policy by designate the triggering of certain inspection policies when a set of criteria has been met ( e.g., if header data matches, for a threshold time interval).”, (see Koottayi Col.39 lines:3-7).
Regarding claim 19 is a computer-implemented method claim that recites similar limitations as the method claim 3 and is being rejected based on the same rational as claim 3.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Kass et al. (US-20130054509-A1 hereafter Kass), in view of Ganesh et al. (US-10296520-B1 hereafter Ganesh), in view of Sakamoto et al. (US-20050203881-A1 hereafter Sakamoto), in further view of Koottayi et al. (US-11265329-B2 hereafter Koottayi).
Regarding claim 7 Kass in view of Ganesh, and Sakamoto discloses the apparatus of claim 1, Kass in view of Ganesh, and Sakamoto appear to be silence on wherein the at least one threat detection policy employed by the threat detection model is generated based at least in part on at least one portion of client input data received via the interactive threat detection dashboard.
However, Koottayi discloses wherein the at least one threat detection policy employed by the threat detection model is generated based at least in part on at least one portion of client input data received via the interactive threat detection dashboard. (See Koottayi Col. 21 lines57-68: “the dynamic enforcement policies comprise rules written/rewritten ( e.g., created by machine learning techniques or an administrator of the system) to evaluate evolving dynamics or attributes of the system in real-time… the static and dynamic policies can be created manually by an administrator or can be injected automatically by a consuming application ( e.g., an application on a target system providing a resource) or the threat detection component 175 into the system 100.”, Col.39 lines: “In certain embodiments, the system may provide an inspection policy UI that allows an administrator to create the inspection policy by designate the triggering of certain inspection policies when a set of criteria has been met ( e.g., if header data matches, for a threshold time interval).”).
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Kass in view of Ganesh, and Sakamoto teaching of claim 1 with Koottayi teaching “the system may provide an enforcement policy UI that allows an administrator to create the dynamic enforcement policy by designate the triggering of certain enforcement actions when a set of attributes has been met (e.g., if a source and destination of a live information flows matches a source and destination of the policy).” (see Koottayi Col.40 lines:16-22).
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Kass et al. (US-20130054509-A1 hereafter Kass), in view of Ganesh et al. (US-10296520-B1 hereafter Ganesh), of Sakamoto et al. (US-20050203881-A1 hereafter Sakamoto), and Muddu et al. (US-20170134415-A1 hereafter Muddu), in further view of Linga et al. (US-20210256089-A1 hereafter Linga).
Regarding claim 14 Kass in view of Ganesh, Sakamoto, and Muddu disclose the apparatus of claim 10, Kass in view of Ganesh, Sakamoto, and Muddu appear to be silence on wherein the code repository alert type is associated with at least one of a mass code repository clone alert, a mass code repository export alert, or a mass code repository commit alert.
However, Linga teaches wherein the code repository alert type is associated with at least one of a mass code repository clone alert, a mass code repository export alert, or a mass code repository commit alert. (See Linga par.104: “The process may also include initiating a code audit operation which identifies the code access events over a period of time based on code events stored in a code log, determining whether a number of code clone events exceeded a clone event threshold, and creating an alert when the clone event threshold is exceeded and locking access to
the sensitive code segments.”).
It would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have combined Kass in view of Ganesh, Sakamoto, and Muddu teaching of claim 10 with Linga teaching “Example embodiments provide ways to enforce software code access and permissions to protect code from unauthorized sources attempting to gain access to the code. Code access, in general, may invoke a managerial event, such as an automated identification procedure to identify whether the code attempting to be accessed, or more specifically, the code segment that was specifically accessed, is permitted to be accessed, altered, etc. Also, a determination may be made as to whether the code was tampered, copied, etc., especially when the profile associated with the access attempt during the code access event has limited rights to access and modify the code.”, (see Linga par.0056).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Zaytsev et al. (US-20240146747-A1) a log-based anomaly classifier on may be implemented to identify brute force activity. The log-based anomaly classifier may be trained based on normal observations of user access and authentications. When anomalous attempts for a single user to fail authentication multiple times are observed, an alert may be triggered at the log-based anomaly classifier. In implementations, the log-based events may be associated with IAM access and authentications. n, the real-time events 202 may include normal behavior, unusual behavior from privileged user account, unauthorized insiders trying to access servers and data, anomalies in outbound network traffic, traffic sent to or from unknown locations, excessive consumption changes in configuration, hidden files, abnormal browsing behavior, suspicious registry entries, unexpected changes, etc. The real-time events 202 may be associated with one or more network/cloud participants such as, the endpoint device(s) 102, server(s) 110, virtual machine(s) 112, application platform(s) 114, database(s)/storage(s) 116.
Baikalov et al. (US-20150033337-A1) allow an enterprise to monitor its assets and detect and respond to real-time threats posed by any particular asset. Architecture 300 may secure a system against threats by monitoring the data transmitted by assets. In some aspects, the data transmitted by assets may include, or be associated with, events. An event may be an action taken by an asset that could serve as a threat to a system or enterprise. Such actions may include, for example, transmitting data over the system, downloading or uploading data, logging into the system, and the like. As an example, a user may attempt to log into the system by entering username and password into workstation 201. The data entered by the user is associated with an event (i.e. logging into the system).
Shahbaz et al. (US-20180091528) users may use such a network security application to configure one or more “modular alerts.” As used herein, a modular alert generally represents a component of a network security application which enables users to specify security modular alert actions to be performed in response to the detection of defined triggering conditions, a modular alert configured to detect potential brute-force login attacks against devices within a network may comprise a query configured to identify event data indicating that a potential brute-force login attack is occurring (e.g., event data reflecting network messages received by devices within the network). The modular alert may further comprise a triggering condition indicating that an occurrence of a potential brute-force login attack is occurring when N or more failed login attempts are received by a particular device within S seconds.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUILIO MUNGUIA whose telephone number is (571)270-5277. The examiner can normally be reached M-F 9:30AM - 5:00PM.
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, Eleni A Shiferaw can be reached at (571) 272-3867. 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.
/DUILIO MUNGUIA/Examiner, Art Unit 2497
/ELENI A SHIFERAW/Supervisory Patent Examiner, Art Unit 2497
Prosecution Insights