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 is a reply to the application filed on 7/21/2025, in which claim(s) 1-19 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 7/21/2025, has been reviewed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the examiner is considering the information disclosure statement.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Drawings
The drawings filed on 7/21/2025 is/are accepted by The Examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim(s) 1-19 is/are rejected on the ground of nonstatutory double patenting over claim(s) 1-20 of U.S. Patent No. 12,388,854 and claim(s) 1-20 of U.S. Patent No. 12,388,841, since the claims, if allowed, would improperly extend the “right to exclude” already granted in the patent.
The subject matter claimed in the instant application is fully disclosed in the patent and is covered by the patent since the patent and the application are claiming common subject matter, as follows: Although the claims are not identical; however, they are fully anticipated by the both of the parent applications.
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 1-19 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 1, 10 and 11 reciting “extracting from the at least an event an identifier of a cloud entity…”. The limitation lacks comma and it’s unclear what it’s trying to claim… what does it mean “extracting from the at least an event an identifier”…
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claim(s) 1-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kirti et al. (US 20150172321 A1; hereinafter Kirti) in view of Thomas et al. (US 20230114821 A1; hereinafter Thomas).
Regarding claims 1, 10 and 11, Kirti discloses a method for improving cloud detection and response (CDR) by generating a normalized event log from a plurality of cloud service providers (CSPs), comprising:
receiving a first event from a cloud computing environment provided by a first CSP and a second event from a cloud computing environment provided by a second CSP (collecting software defined security configuration data about the cloud application's security controls. The software defined security configuration data can be collected by utilizing an API made available by the cloud application. API's and classes of API's that may be utilized in accordance with embodiments may include REST, J2EE, SOAP, and native programmatic methods. The information could also be requested using other techniques including scripting languages, deployment descriptors, log files, database connectivity through JDBC or REST, and resident applications as will be discussed further below. The information that is sent or received can be represented in a variety of formats including, but not limited to, JSON, XML, and CSV. One skilled in the art will recognize that any of a variety of formats may be utilized in accordance with embodiments of the invention as suitable to a specific application. Table 1 below provides a partial list of security controls and the access that is supported by the cloud applications Box and Amazon Web Services [Kirti; ¶63-64, 69-74, 90; Table 1 and 2]);
generating a first normalized event based on data extracted from the first event and a predefined data schema (extracting data from the retrieved activity data including security and activity data [Kirti; Fig. 3 step 304, 4 step 404 and associated text], generate security controls metadata, that is, normalized descriptors for entering the information into a common database. Information provided to the controls management platform can be retrieved from an application catalog database using metadata based schema mapping [Kirti; ¶69-84; Fig. 3 step 306, 4 step 410]);
generating a second normalized event based on data extracted from the second event and further based on the predefined data schema (another additional embodiment also includes normalizing the retrieved activity data into a common format using the cloud security system [Kirti; ¶69-84; Fig. 3 step 306, 4 step 410]);
storing the first normalized event and the second normalized event in a normalized log (categorize and storing in catalog and analytics database, activity data can include sources of information such as a user log(s) or audit trail(s), may be available as log files or database entries [Kirti; ¶69-84; Fig. 3 step 306, 408, 4 step 408, 410]);
detecting a cybersecurity threat based on at least an event of the normalized log (security controls can be used to generate security controls metadata, that is, normalized descriptors for entering the information into a common database. The security controls metadata is categorized and indexed. The categorization may comply with a standard specified by a security organization and/or may be certified and/or audited used in detecting threats [Kirti; ¶3, 69-84; Fig. 3 step 306, 408, 4 step 408, 410]);
[[extracting from the at least an event]] an identifier of a cloud entity (a cloud security monitoring and control identified the threats in a first cloud (e.g., a query from a blocked IP address) [Kriti; ¶116]). Kirti does not explicilty discloses extracting from the at least an event an identifier of a cloud entity; however, in a related and analogous art, Thomas teaches this feature.
In particular, Thomas teaches monitor events on the event stream, and enrich these events in any suitable manner. This may include formatting the events according to one or more schemas for the event stream, normalizing the events for consistent representation of events from different sources, filtering the events to remove duplicate or unnecessary data, augmenting the events to provide additional data, mapping event data to known threat types, processing events to generate additional events for publication to the event stream, and obtaining security data from a cloud service. While an enrichment broker may conveniently access external resources to enrich data on an event stream, an enterprise network may also use any of a variety of cloud services to support users associated with the enterprise network. This can create additional challenges such as accessing user data and application usage data from the cloud service(s) and converting any resulting data feeds to be consistent in form and content with data in the data lake from other sources and using a flat schema employing columnar storage organized by fields such as a user name, time, device, and the like. The data objects in the data lake may also be organized for ease of use, e.g., by placing identifiers or other high level metadata in a small separate file, by placing commonly used data (e.g., extracted or derived data for analytics dashboards, real time event listening, and the like) in a second, small file, and by placing remaining data into a larger data file for access if/when needed [Thomas; ¶104-113, 202, 270-284; figs. 5, 19-20 and associated text]);
querying a security database to detect a representation the cloud entity (analytics and threat intelligence repository database may be any database or data repository with query capability to identify malware activity, and failures and critical errors [Kriti; ¶82-85, 116]);
determining that the detected representation is associated with a cybersecurity risk (cloud security monitoring and control in accordance with embodiments of the invention can automatically notify a second cloud that is part of the business process. The notification can include a request or recommendation for a higher level of security controls or other forms of remediate [Kriti; ¶3, 69-84, 87-90, 116], event graph such as the event graph shown in the figure may include any number of nodes and edges, where computing objects are represented by nodes and events are represented by edges that mark the causal or otherwise directional relationships between computing objects such as data flows, control flows, network flows and SO forth. While processes or files are common forms of nodes that might appear in such a graph, any other computing object such as an IP address, a registry key, a domain name, a uniform resource locator, a command line input or other object may also or instead be designated to be a node in an event graph as contemplated herein. Similarly, while an edge may be formed by an IP connection, a file read, a file write, a process invocation (parent, child, etc.), a process path, a thread injection, a registry write, a domain name service query, a uniform resource locator access and so forth other edges may be designated. As described above, when a security event is detected, the source of the security event may serve as a starting point within the event graph, which may then be traversed backward to identify a root cause using any number of suitable cause identification rules. The event graph may then usefully be traversed forward from that root cause to identify other computing objects that are potentially tainted by the root cause so that a more complete remediation can be performed [Thomas; ¶104-113, 270-284; figs. 5, 19-20 and associated text]); and
initiating an active response in a cloud computing environment associated with the cloud entity, based on the cybersecurity risk and the detected cybersecurity threat (select a security policy to implement in response to the identified threat, events along with actions that a user can take in response to or to remediate an event. Alerts can be constructed based on pre-defined rules that can include specific events and thresholds, clustering can be used to detect outliers and anomalous activity [Kirti; ¶3, 69-84, 87-90], facilitate prompt notification of potential risks, the threat management facility may incrementally update data for use in threat assessments as the data becomes available from these different sources, and create suitable alerts or notifications whenever the currently accumulated data provides an indication of threat meeting a predetermined threshold [Thomas; ¶5-7, 104-113, 194, 211; figs. 5, 19-20 and associated text]). It would have been obvious before the effective filing date of the claimed invention to modify Kirti in view of Thomas with the motivation to better protect enterprises against cybersecurity threats [Thomas; ¶46].
Regarding claims 2 and 12, Kirti-Thomas combination discloses further comprising: detecting in the security database the cloud computing environment associated with the cloud entity (a cloud security monitoring and control identified the threats in a first cloud (e.g., a query from a blocked IP address) [Kriti; ¶116]).
Regarding claims 3 and 13, Kirti-Thomas combination discloses further comprising: extracting data from a data field of the first event; and storing the extracted data in the first normalized event based on the predefined data schema including a plurality of data fields (extracting data from the retrieved activity data including security and activity data [Kirti; Fig. 3 step 304, 4 step 404 and associated text], generate security controls metadata, that is, normalized descriptors for entering the information into a common database. Information provided to the controls management platform can be retrieved from an application catalog database using metadata based schema mapping [Kirti; ¶69-84; Fig. 3 step 306, 4 step 410]).
Regarding claims 4 and 14, Kirti-Thomas combination discloses further comprising: determining that a value of a data field of the at least an event matches a condition of a rule; and triggering the active response based on a result of applying the condition on the at least an event (utilized to implement security policies by setting security controls within a tenant's accounts in various cloud applications. As will be discussed in greater detail further below, a cloud seeder may set security controls in various conditions, which is constructed based on pre-defined rules that can include specific events and thresholds [Kirti; ¶67-84; Fig. 3 step 306, 4 step 410]).
Regarding claims 5 and 15, Kirti-Thomas combination discloses further comprising: generating another normalized event based on data extracted from the first even and data extracted from the second event (generate a threat model using at least a first and second portions of stored activity data in the analytics repository database includes the processor being configured to generate a threat model using a machine learning algorithm of stored activity data [Kirti; ¶22-23]).
Regarding claims 6 and 16, Kirti-Thomas combination discloses further comprising: receiving a plurality of events from any one of: a queue, an event stream, or a combination thereof (access patterns and other event statistics enables the system to establish baselines [Kirti; ¶21, 60-62, 72]).
Regarding claims 7 and 17, Kirti-Thomas combination discloses further comprising: generating a unique normalized event corresponding to each unique event of the received plurality of events (normalize the retrieved activity data into a common format [Kirti; ¶21, 60-62, 72]).
Regarding claims 8 and 18, Kirti-Thomas combination discloses further comprising: generating an event cluster including the first normalized event and the second normalized event (normalize the retrieved activity data into a common format, categorization may comply with a standard specified by a security organization and/or may be certified and/or audited and put data into clusters by aggregating all entries [Kirti; ¶21, 60-62, 72, 89]).
Regarding claims 9 and 19, Kirti-Thomas combination discloses further comprising: generating the event cluster based on any one of: a data field of the predefined data schema, a value of a data field of the predefined data schema, or any combination thereof (various types of algorithms can be particularly useful for analyzing the data. Decision tree, time series, naive Bayes analysis, and techniques used to build user behavior profiles are examples of machine learning techniques that can be utilized to generate predictions based on patterns of suspicious activity and/or external data feeds. Techniques such as clustering can be used to detect outliers and anomalous activity. For example, a threat can be identified based on an account accessing one or more files or failing a series of login attempts from an IP address that is flagged (by a third party feed or otherwise) as malicious. In a similar way, a threat can also be based on different patterns of activity in one cloud or across multiple clouds over a series of time. As discussed further above, activity data from different clouds may be in different formats or with different possible values or ranges of values. Normalizing the data in the processes discussed above may include reformatting the data such that it is comparable, have the same meaning, and/or bear the same significance and relevance between different clouds. Thus, algorithms can aggregate and compare data from different clouds in meaningful ways. For example, a series of failed logins with a particular user account in one cloud may be deemed not to be a threat. However, a series of failed logins with user accounts associated with a user across multiple clouds may indicate a concerted effort to crack the user's password and therefore set off an alarm. Clustering and regression algorithms can be used to categorize data and find common patterns. For example, a clustering algorithm can put data into clusters by aggregating all entries of users logging in from a mobile device. Predictive analytics can also include identifying threats based on activity such as a user not accessing a particular cloud application in several months and then showing high activity in the next month or a user downloading one file every week for the past several weeks, demonstrating a potential advanced persistent threat (APT) scenario. In several embodiments of the invention, data collected over time is used to build models of normal behavior (e.g., patterns of events and activity) and flag behavior that deviates from normal as abnormal behavior. After one or more flagged event or activity is characterized as a true or false positive (e.g., by user feedback), the information can be provided back to one or more machine learning algorithms to automatically modify parameters of the system. Thus, machine learning algorithms can be utilized in at least the ways discussed above to make recommendations and reduce false alarms (false positives). Activity data collected from various parameters over period of time can be used with machine learning algorithms to generate patterns referred to as user behavior profiles. The activity data can include contextual information such as IP address and geographic location [Kirti; ¶21, 60-62, 72, 89]).
Internet Communications
Applicant is encouraged to submit a written authorization for Internet communications (PTO/SB/439, http:ljwww.uspto.gov/sites/default/files/documents/sb0439.pdf) in the instant patent application to authorize the examiner to communicate with the applicant via email. The authorization will allow the examiner to better practice compact prosecution. The written authorization can be submitted via one of the following methods only: (1) Central Fax which can be found in the Conclusion section of this Office action; (2) regular postal mail; (3) EFS WEB; or (4) the service window on the Alexandria campus. EFS web is the recommended way to submit the form since this allows the form to be entered into the file wrapper within the same day (system dependent). Written authorization submitted via other methods, such as direct fax to the examiner or email, will not be accepted. See MPEP § 502.03.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DAO Q HO whose telephone number is (571)270-5998. The examiner can normally be reached on 7:00am - 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, Jeffrey Nickerson can be reached on (469) 295-9235. 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.
/DAO Q HO/Primary Examiner, Art Unit 2432
Prosecution Insights