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 .
Claim Objections
Claim 8 objected to because of the following informalities:
Claim 8 is grammatically incorrect. The recommended change is “The enterprise security system of claim 7, wherein the vSensor is communicatively coupled to a container service to receive metadata associated with network traffic data between the first cloud resource and the second cloud resource of the plurality of cloud resources; The second cloud resource being part of a Kubernetes cluster.”
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“A cloud resource enumeration component configured” in claim 1
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
Claim 1 is 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.
Claim limitation “A cloud resource enumeration component configured …” invokes 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, material, or acts for performing the entire claimed function and to clearly link the structure, material, or acts to the function. The specification does not provide any structure for performing the claimed functions. There is no disclosure of any particular structure, either explicitly or inherently, to perform functions “autonomously identify one or more cloud architectures …” and “collect metadata associated with the plurality of cloud resources”. Therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
Applicant may:
(a) Amend the claim so that the claim limitation will no longer be interpreted as a limitation under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph;
(b) Amend the written description of the specification such that it expressly recites what structure, material, or acts perform the entire claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(c) Amend the written description of the specification such that it clearly links the structure, material, or acts disclosed therein to the function recited in the claim, without introducing any new matter (35 U.S.C. 132(a)).
If applicant is of the opinion that the written description of the specification already implicitly or inherently discloses the corresponding structure, material, or acts and clearly links them to the function so that one of ordinary skill in the art would recognize what structure, material, or acts perform the claimed function, applicant should clarify the record by either:
(a) Amending the written description of the specification such that it expressly recites the corresponding structure, material, or acts for performing the claimed function and clearly links or associates the structure, material, or acts to the claimed function, without introducing any new matter (35 U.S.C. 132(a)); or
(b) Stating on the record what the corresponding structure, material, or acts, which are implicitly or inherently set forth in the written description of the specification, perform the claimed function. For more information, see 37 CFR 1.75(d) and MPEP §§ 608.01(o) and 2181.
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 1 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. As described above, the disclosure does not provide structure to perform the claimed functions of autonomously identifying one or more cloud architectures and collecting metadata associated with cloud resources. The specification does not demonstrate that applicant has made an invention that achieves the claimed function because the invention is not described with sufficient detail such that one of ordinary skill in the art can reasonably conclude that the inventor had possession of the claimed invention.
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.
Claim(s) 1-2, 4-7, and 10 -12, 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20260046210 A1 (hereinafter referred to as Jegarajan) over US 11366680 B2 (hereinafter referred to as Levin)
As per claim 1 – Jegarajan teaches an enterprise security system, comprising: a cyber security system having a cloud resource enumeration component (As shown, the topology system logic 138 is in communication with the controller 102 – [0034]; the topology system logic corresponds to the “cloud resource enumeration component”) configured to (i) autonomously identify one or more cloud architectures assembled from a plurality of cloud resources within a customer cloud environment (According to one embodiment, the system may include a software instance that is operating in one or more cloud computing resources and is configured to collect information and render a graphic user interface (GUI) that provides an interactive, visual rendering of the connectively between constructs of a network spanning multiple (two or more) cloud computing environments (hereinafter, a “multi-cloud computing environment or a “multi-cloud network”) – [0013]; The system collecting and rendering information on the connectivity between constructs corresponds to “autonomously identify one or more cloud architectures …”) and (ii) collect metadata associated with the plurality of cloud resources (the software instance may query the controller for information using one or more Application Programming Interface (API) calls to retrieve information stored by the controller detailing status information of each construct managed by the controller. The controller obtains such information from one or more gateways deployed within a multi-cloud network, where the gateway(s) are configured to transmit this information to the controller on a periodic (or aperiodic) basis – [0014]; The software instance retrieving information on each construct managed by the controller corresponds to “collect metadata associated …”).
Jegarajan does not teach the following limitations:
and a cyber security appliance communicatively coupled to the cyber security system, the cyber security appliance is configured to build and maintain dynamic AI-based models with the plurality of cloud resources within the customer cloud environment and the metadata associated with the plurality of cloud resources from the cloud resource enumeration component, where the cyber security appliance is configured to determine, based on operations conducted by a first AI-based model representative of a normal behavior of a cloud resource of the plurality of cloud resources or a second AI-based model representative of a normal behavior of a cloud architecture of the one or more cloud architectures, whether characteristics and operability of the cloud resource or the cloud architecture within the customer cloud environment is subject to a cyberthreat by detecting deviations from the normal behavior of the cloud resource or the normal behavior of the cloud architecture, where any portions of the cyber security system and the cyber security appliance having software instructions are stored on one or more non-transitory computer readable mediums in an executable state by one or more processors.
However, Levin, in an analogous art, teaches them as can be seen in the in-line citations below:
and a cyber security appliance communicatively coupled to the cyber security system (The network interface 240 allows the CNVM runtime protector 200 to communicate for the purpose of, for example, receiving training data sets, uploading normal behavior models to cloud services, and the like. Additionally, the network interface 240 may be utilized to send alerts indicating deviations from normal behaviors with respect to capabilities to external systems configured to perform mitigation actions with respect to the abnormally behaving cloud native VM – [col 7; lines 40-45]; The CNVM runtime protector corresponds to the “cyber security appliance” of the claim. The network interface being connected to external systems in order to collect training data or send alerts when deviations are detected corresponds to the cyber security appliance being “communicatively coupled to the cyber security system”.), the cyber security appliance is configured to build and maintain dynamic AI-based models (The ML module 250 is configured to train a machine learning model based on a training dataset. The machine learning model defines a baseline normal behavior of a cloud native VM and, in particular, capabilities indicating required behaviors of each service provided by the VM – [col 7; lines 35-39]) with the plurality of cloud resources within the customer cloud environment and the metadata associated with the plurality of cloud resources from the cloud resource enumeration component (The training data set may be received or may be collected based on monitoring of activities by the cloud native VM. The training set includes training activities performed by services of the cloud native VM. The training activities may include, for example, processes (e.g., binaries) run by a service, file paths used by the service, and the like – [col 5-6; lines 66-5]; The services (processes run, file paths used, etc.) of the cloud native VM correspond to the “plurality of cloud resources … and the metadata associated with the plurality of cloud resources …”), where the cyber security appliance is configured to determine, based on operations conducted by a first AI-based model representative of a normal behavior of a cloud resource of the plurality of cloud resources or a second AI-based model representative of a normal behavior of a cloud architecture of the one or more cloud architectures, whether characteristics and operability of the cloud resource or the cloud architecture within the customer cloud environment is subject to a cyberthreat by detecting deviations from the normal behavior of the cloud resource or the normal behavior of the cloud architecture (creating a normal behavior model for a cloud native VM by training a machine learning model using a training data set including a plurality of training activities performed by the cloud native VM, the cloud native VM being configured to provide at least one service, wherein the normal behavior model defines at least one capability of each of the at least one service, wherein each capability of a service indicates a plurality of discrete behaviors required by the service; and monitoring an execution of the cloud native VM to detect a deviation from the normal behavior model, wherein the deviation is caused by at least one abnormal behavior of one of the at least one service that is not among the discrete behaviors defined in the at least one capability for the service – [col 2; lines 14-27]; The normal behavior model corresponds to “a first AI-based model representative of a normal behavior of a cloud resource …” and “monitoring the execution of the cloud native VM to detect a deviation from the normal behavior model corresponds to “determine … is subject to a cyberthreat by detecting deviations from the normal behavior of the cloud resource”), where any portions of the cyber security system and the cyber security appliance having software instructions are stored on one or more non-transitory computer readable mediums in an executable state by one or more processors (The system comprises: a processing circuitry; and a memory, the memory containing instructions that, when executed by the processing circuitry, configure the system to – [col 2; lines 46-49]).
This combination would have been obvious to one of ordinary skill in the art because of the explicitly stated benefit in Levin of using a cyber security machine learning model in a cyber security system to autonomously detect cyber threats. Levin notes “existing solutions for providing runtime security defense utilize a server or other external system that interacts with an application. Although runtime security defense may be integrated within the application itself, such integration requires manual modification of the application code by a programmer. This is inconvenient, as the application owner must either allow access to the code by the service provider or hire a programmer to perform the integration. Also, the manual integration is subject to human error that may cause bugs or other issues with the integrated code” [col. 1; lines 50-60] and further states that “It would be advantageous to provide a solution that would overcome the challenges noted above” [col. 1; lines 61-62], with the solution being the proposed invention. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date to incorporate the machine learning model used for detecting anomalous behavior of Levin to the cloud network topology mapping system of Jegarajan.
As per claim 2 –The combination of Jegarajan and Levin teach the system of claim 1, Jegarajan further teaches wherein:
the cyber security system comprises a plurality of components to collect metadata associated with a first cloud resource of the plurality of cloud resources and a storage subsystem to store the metadata corresponding to the first cloud resource within the storage subsystem (In some embodiments, the communication interface logic 214, upon execution by one or more processors, performs operations as discussed herein pertaining to querying a controller for construct metadata, receiving the requested construct metadata and receiving the network data from one or more gateways managed by the controller. In some embodiments, the received construct metadata and network data may be stored in the construct metadata database 220 and the network data database 222 (which may be separate or a combined database) – [0054]; The communication interface logic receiving construct metadata and storing it in the construct metadata database).
As per claim 4 - The combination of Jegarajan and Levin teach the system of claim 1, Jegarajan further teaches:
where the cloud resource enumeration component is further configured to conduct mapping of the cloud resources, and wherein the cyber security system is deployed as part of a local on-premises network of a customer (In some embodiments, the topology system logic 138 may be logic hosted on a user's Infrastructure as a Service (IaaS) cloud – [0033]; a user’s Infrastructure as a Service cloud corresponds to the “local on-premises network of a customer”).
As per claim 5 The combination of Jegarajan and Levin teach the system of claim 1, Jegarajan further teaches wherein:
the cyber security system is communicatively coupled to the customer cloud environment via a cloud provider application programming interface (API) (As shown, the topology system logic 138 is in communication with the controller 102 via, for example, an API that enables the topology system logic 138 to transmit queries to the controller 102 via one or more API calls – [0034]; the topology system being in communication via an API teaches the claim limitation).
As per claim 6 – The combination of Jegarajan and Levin teach the system of claim 1, Jegarajan further teaches wherein:
the cyber security system is further communicatively coupled to (i) receive flow log data, (ii) determine one or more cloud resources of the plurality of cloud resources associated with the flow log data and (iii) store the flow log data as part of the metadata for the one or more cloud resources (In some embodiments, the communication interface logic 214, upon execution by one or more processors, performs operations as discussed herein pertaining to querying a controller for construct metadata, receiving the requested construct metadata and receiving the network data from one or more gateways managed by the controller. In some embodiments, the received construct metadata and network data may be stored in the construct metadata database 220 and the network data database 222 (which may be separate or a combined database) – [0054]; By querying the controller for construct metadata and receiving network data from one or more gateways, the topology system logic may generate the exemplary visualizations described above, and those shown in the accompanying drawings, that illustrate the flow of network traffic associated with one or more tagged constructs – [0018]; receiving construct network data corresponds to “receive flow log data”, illustrating the flow of network traffic through one or more constructs using the network data corresponds to “determining one or more of the plurality of cloud resources associated with the flow log data”, and storing the network data in the network data database corresponds to “store the flow log data as part of the metadata for the one or more cloud resource”).
As per claim 7 – The combination of Jegarajan and Levin teach the system of claim 1, Jegarajan further teaches wherein:
the cyber security system is further communicatively coupled to a vSensor to (i) receive metadata associated with network traffic data between a first cloud resource and a second cloud resource of the plurality of cloud resources and (ii) store the metadata associated with the network traffic data as metadata for the first cloud resource or the second cloud resource (In some embodiments, the communication interface logic 214, upon execution by one or more processors, performs operations as discussed herein pertaining to querying a controller for construct metadata, receiving the requested construct metadata and receiving the network data from one or more gateways managed by the controller. In some embodiments, the received construct metadata and network data may be stored in the construct metadata database 220 and the network data database 222 (which may be separate or a combined database) – [0054]; receiving and storing network data for a construct teaches the claim limitation).
As per claim 10 – The combination of Jegarajan and Levin teach the system of claim 1, Jegarajan further teaches:
further comprising: an output system communicatively coupled to the cyber security system, wherein the output system is configured to receive information pertaining to the one or more cloud architectures for generation of a graphical representation of the one or more cloud architectures (According to one embodiment, the system may include a software instance that is operating in one or more cloud computing resources and is configured to collect information and render a graphic user interface (GUI) that provides an interactive, visual rendering of the connectively between constructs of a network spanning multiple (two or more) cloud computing environments (hereinafter, a “multi-cloud computing environment or a “multi-cloud network”) – [0013]; The software instance being configured to render a GUI that depicts the connectivity between constructs of the network corresponds to the claim limitation).
As per claim 11 – Jegarajan teaches a computerized method for securing a customer cloud environment, comprising: identifying a plurality of cloud resources within the cloud environment; collecting metadata associated with the plurality of cloud resources; determining one or more cloud architectures assembled from at least a subset of the plurality of cloud resources (According to one embodiment, the system may include a software instance that is operating in one or more cloud computing resources and is configured to collect information and render a graphic user interface (GUI) that provides an interactive, visual rendering of the connectively between constructs of a network spanning multiple (two or more) cloud computing environments (hereinafter, a “multi-cloud computing environment or a “multi-cloud network”) – [0013]; The system collecting and rendering information on the connectivity between constructs corresponds to “autonomously identify one or more cloud architectures …”); storing at least the metadata associated with the plurality of cloud resources with a storage subsystem (the software instance may query the controller for information using one or more Application Programming Interface (API) calls to retrieve information stored by the controller detailing status information of each construct managed by the controller. The controller obtains such information from one or more gateways deployed within a multi-cloud network, where the gateway(s) are configured to transmit this information to the controller on a periodic (or aperiodic) basis – [0014]; The software instance retrieving information on each construct managed by the controller corresponds to “collect metadata associated …”).
It does not teach the following limitations:
and determining, based on operations conducted by a first AI-based model representative of a normal behavior of a cloud resource of the plurality of cloud resources or a second AI-based model representative of a normal behavior of a cloud architecture of the one or more cloud architectures, whether characteristics or operability of the cloud resource or the cloud architecture within the customer cloud environment is subject to a cyberthreat.
However, Levin, in an analogous art, teaches them as can be seen in the in-line citations below:
and determining, based on operations conducted by a first AI-based model representative of a normal behavior of a cloud resource of the plurality of cloud resources or a second AI-based model representative of a normal behavior of a cloud architecture of the one or more cloud architectures (The ML module 250 is configured to train a machine learning model based on a training dataset. The machine learning model defines a baseline normal behavior of a cloud native VM and, in particular, capabilities indicating required behaviors of each service provided by the VM – [col 7; lines 35-39]), whether characteristics or operability of the cloud resource or the cloud architecture within the customer cloud environment is subject to a cyberthreat (creating a normal behavior model for a cloud native VM by training a machine learning model using a training data set including a plurality of training activities performed by the cloud native VM, the cloud native VM being configured to provide at least one service, wherein the normal behavior model defines at least one capability of each of the at least one service, wherein each capability of a service indicates a plurality of discrete behaviors required by the service; and monitoring an execution of the cloud native VM to detect a deviation from the normal behavior model, wherein the deviation is caused by at least one abnormal behavior of one of the at least one service that is not among the discrete behaviors defined in the at least one capability for the service – [8]; This process teaches the claim limitation).
As per claim 12 – The combination of Jegarajan and Levin teach the computerized method of claim 11. Jegarajan further teaches:
wherein the collecting of the metadata associated with the plurality of cloud resources comprises collecting metadata associated with a first cloud resource of the plurality of cloud resources (In some embodiments, the communication interface logic 214, upon execution by one or more processors, performs operations as discussed herein pertaining to querying a controller for construct metadata, receiving the requested construct metadata and receiving the network data from one or more gateways managed by the controller. In some embodiments, the received construct metadata and network data may be stored in the construct metadata database 220 and the network data database 222 (which may be separate or a combined database) – [0054]; The communication interface logic receiving construct metadata and storing it in the construct metadata database teaches the claim).
As per claim 14 – The combination of Jegarajan and Levin teach the computerized method of claim 11. Jegarajan further teaches:
further comprising: receiving flow log data; determining one or more cloud resources of the plurality of cloud resources associated with the flow log data; and storing the flow log data as part of the metadata for the one or more cloud resources(In some embodiments, the communication interface logic 214, upon execution by one or more processors, performs operations as discussed herein pertaining to querying a controller for construct metadata, receiving the requested construct metadata and receiving the network data from one or more gateways managed by the controller. In some embodiments, the received construct metadata and network data may be stored in the construct metadata database 220 and the network data database 222 (which may be separate or a combined database) – [0054]; By querying the controller for construct metadata and receiving network data from one or more gateways, the topology system logic may generate the exemplary visualizations described above, and those shown in the accompanying drawings, that illustrate the flow of network traffic associated with one or more tagged constructs – [0018]; receiving construct network data corresponds to “receive flow log data”, illustrating the flow of network traffic through one or more constructs using the network data corresponds to “determining one or more of the plurality of cloud resources associated with the flow log data”, and storing the network data in the network data database corresponds to “store the flow log data as part of the metadata for the one or more cloud resource”).
Claim(s) 3 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jegarajan in view of Levin further in view of “Improve Resource-sharing through Functionality-preserving Merge of Cloud Application Topologies” (hereinafter referred to as Binz, pub. 2013).
As per claim 3 – The combination of Jegarajan and Levin teach the system of claim 2, Jegarajan further teaches:
wherein the cyber security appliance is configured to operate by at least (i) conducting operations in accordance with a discovery phase that includes identifying the one or more cloud architectures assembled from the plurality of cloud resources within the customer cloud environment (According to one embodiment, the system may include a software instance that is operating in one or more cloud computing resources and is configured to collect information and render a graphic user interface (GUI) that provides an interactive, visual rendering of the connectively between constructs of a network spanning multiple (two or more) cloud computing environments (hereinafter, a “multi-cloud computing environment or a “multi-cloud network”) – [0013]; collecting information on the connectivity between constructs of a network spanning multiple cloud computing environments teaches this limitation) and collecting the metadata associated with the plurality of cloud resources forming the one or more cloud architectures (the software instance may query the controller for information using one or more Application Programming Interface (API) calls to retrieve information stored by the controller detailing status information of each construct managed by the controller. The controller obtains such information from one or more gateways deployed within a multi-cloud network, where the gateway(s) are configured to transmit this information to the controller on a periodic (or aperiodic) basis – [0014]; querying an API for information of each construct teaches this limitation), (ii) conducting operations in accordance with an architecture formation phase that includes conceptualizing the one or more cloud architectures from the plurality of cloud resources (configured to collect information and render a graphic user interface (GUI) that provides an interactive, visual rendering of the connectively between constructs of a network spanning multiple (two or more) cloud computing environments (hereinafter, a “multi-cloud computing environment or a “multi-cloud network”) – [0013]; visually rendering a GUI that shows the connectivity of cloud networks teaches this limitation).
The combination of Jegarajan and Levin does not teach the following limitations:
and (iii) conducting operations in accordance with an architecture reduction phase that includes merging at least a first cloud architecture and a second cloud architecture of the one or more cloud architectures determined to be sharing at least a prescribed number of the plurality of cloud resources and having compatible policies.
However, Binz, in an analogous art, teaches them as can be seen in the in-line citations below:
and (iii) conducting operations in accordance with an architecture reduction phase that includes merging at least a first cloud architecture and a second cloud architecture of the one or more cloud architectures determined to be sharing at least a prescribed number of the plurality of cloud resources (To reduce cost, the company decides to migrate these customer-facing applications to the cloud, in this case to Amazon EC2. However, running the same supporting infrastructure three times is not efficient. To further reduce cost, the company looks for a solution to automatically merge application topologies – [97]; For functionality-preserving merging of application topologies we propose a method which defines five sequential steps, presented in the following subsections: (i) Identify Applications to be Merged, (ii) Matching, (iii) Manual Evaluation, (iv) Merging, and (v) Final Evaluation & Deployment – [98]; This teaches a method of merging application topologies because of repetitive resource usage across applications) and having compatible policies (For example, it is not possible to determine in a generic way if the values 32 and 64 for the property CPU architecture are compatible. Some software products may offer versions for both, 32-bit and 64-bit systems, some not. Therefore, our approach uses plugins to integrate the type-specific logic which checks if two nodes (or edges) can be merged or not – [98]; This teaches a compatibility check).
This combination would have been obvious to one of ordinary skill in the art because of the benefit of merging cloud architectures in order to reduce costs mentioned in Binz: “To further reduce cost, the company looks for a solution to automatically merge application topologies. In addition, an important goal is to preserve the functionality provided by the applications. This is where the approach proposed in this paper is aimed to” [97]. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate the cloud architecture merging process of Binz to the cloud network topology formation system of Jegarajan.
As per claim 13 –The combination of Jegarajan and Levin teach the computerized method of claim 11. Jegarajan further teaches:
further comprising: conducting operations in accordance with an architecture formation phase that includes conceptualizing the one or more cloud architectures from the plurality of cloud resources (According to one embodiment, the system may include a software instance that is operating in one or more cloud computing resources and is configured to collect information and render a graphic user interface (GUI) that provides an interactive, visual rendering of the connectively between constructs of a network spanning multiple (two or more) cloud computing environments (hereinafter, a “multi-cloud computing environment or a “multi-cloud network”) – [0013]; visually rendering a GUI that shows the connectivity of cloud networks teaches this limitation);
It does not teach the following limitation:
and conducting operations in accordance with an architecture reduction phase that includes merging at least a first cloud architecture and a second cloud architecture of the one or more cloud architectures determined to be sharing at least a prescribed number of the plurality of cloud resources and having compatible policies.
However, Binz, in an analogous art, teaches it as can be seen in the in-line citations below:
and conducting operations in accordance with an architecture reduction phase that includes merging at least a first cloud architecture and a second cloud architecture of the one or more cloud architectures determined to be sharing at least a prescribed number of the plurality of cloud resources (To reduce cost, the company decides to migrate these customer-facing applications to the cloud, in this case to Amazon EC2. However, running the same supporting infrastructure three times is not efficient. To further reduce cost, the company looks for a solution to automatically merge application topologies – [97]; For functionality-preserving merging of application topologies we propose a method which defines five sequential steps, presented in the following subsections: (i) Identify Applications to be Merged, (ii) Matching, (iii) Manual Evaluation, (iv) Merging, and (v) Final Evaluation & Deployment – [98]; This teaches a method of merging application topologies because of repetitive resource usage across applications) and having compatible policies (For example, it is not possible to determine in a generic way if the values 32 and 64 for the property CPU architecture are compatible. Some software products may offer versions for both, 32-bit and 64-bit systems, some not. Therefore, our approach uses plugins to integrate the type-specific logic which checks if two nodes (or edges) can be merged or not – [98]; This teaches a compatibility check).
Claim(s) 8 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jegarajan in view of Levin further in view of US 11126493 B2 (hereinafter referred to as Guha).
As per claim 8 - The combination of Jegarajan and Levin teach the system of claim 7. It does not teach the following limitations:
wherein the vSensor is communicatively coupled to a container service to receive metadata associated with network traffic data between the first cloud resource and the second cloud resource of the plurality of cloud resources being part of a Kubernetes cluster.
However, Guha, in an analogous art, teaches them as can be seen in the in-line citations below:
wherein the vSensor is communicatively coupled to a container service to receive metadata associated with network traffic data between the first cloud resource and the second cloud resource of the plurality of cloud resources being part of a Kubernetes cluster (In step 302, process 300 can ingest the application's configuration, events, metrics, etc. In step 304, process 300 can collect infrastructure/cloud, orchestration and/or application layer information – [39]; It is noted that the application graph represents the structural topology and directional dependencies across all three layers: the application layer 102, the orchestration (e.g. Kubernetes) layer 104, and the infrastructure (cloud) layer 106 – [49]).
This combination would have been obvious to one of ordinary skill in the art because of the need for monitoring Kubernetes clusters or other container orchestration services stated in Guha: “Containers introduce several layers of abstraction between the application and the underlying hardware to ensure portability and scalability. This can contribute to a significant blind spot when it comes to conventional monitoring. Accordingly, there is an increased need to document and record the interdependent components containers across the various layers of the application environment” [col. 1; lines 32-38]. Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to combine the orchestration layer monitoring process of Guha with the cloud network topology formation system of Jegarajan.
As per claim 15 - The combination of Jegarajan and Levin teach the computerized method of claim 11. Jegarajan further teaches:
further comprising: receiving metadata associated with network traffic data between a first cloud resource and a second cloud resource of the plurality of cloud resources subsystem (In some embodiments, the communication interface logic 214, upon execution by one or more processors, performs operations as discussed herein pertaining to querying a controller for construct metadata, receiving the requested construct metadata and receiving the network data from one or more gateways managed by the controller. In some embodiments, the received construct metadata and network data may be stored in the construct metadata database 220 and the network data database 222 (which may be separate or a combined database) – [0054]; The communication interface logic receiving construct metadata and storing it in the construct metadata database) and storing the metadata associated with the network traffic data as metadata for one or more of the first cloud resource and the second cloud resource (In some embodiments, the received construct metadata and network data may be stored in the construct metadata database 220 and the network data database 222 (which may be separate or a combined database) – [0054]).
It does not teach the following limitation:
wherein the first cloud resource and the second cloud resource being part of a Kubernetes cluster within the customer cloud environment.
However, Guha, in an analogous art, teaches it as can be seen in the in-line citation below:
wherein the first cloud resource and the second cloud resource being part of a Kubernetes cluster within the customer cloud environment (In step 302, process 300 can ingest the application's configuration, events, metrics, etc. In step 304, process 300 can collect infrastructure/cloud, orchestration and/or application layer information – [39]; It is noted that the application graph represents the structural topology and directional dependencies across all three layers: the application layer 102, the orchestration (e.g. Kubernetes) layer 104, and the infrastructure (cloud) layer 106 – [49]).
As per claim 17 – The combination of Jegarajan, Levin, and Guha teach the computerized method of claim 15. Jegarajan further teaches:
further comprising: generating graphical representation of the one or more cloud architectures based, at least in part, on the metadata associated with a subset of the plurality of cloud resources assembled to form the one or more cloud architectures (According to one embodiment, the system may include a software instance that is operating in one or more cloud computing resources and is configured to collect information and render a graphic user interface (GUI) that provides an interactive, visual rendering of the connectively between constructs of a network spanning multiple (two or more) cloud computing environments (hereinafter, a “multi-cloud computing environment or a “multi-cloud network”) – [0013]; The software instance being configured to render a GUI that depicts the connectivity between constructs of the network corresponds to the claim limitation).
Claim(s) 9 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jegarajan in view of Levin further in view of US 20210397903 A1 (hereinafter referred to as Raj).
As per claim 9 – The combination of Jegarajan and Levin teach the system of claim 7. It does not teach the following limitations:
wherein the cyber security system is further communicatively coupled to (i) receive user data, (ii) determine one or more cloud resources of the plurality of cloud resources associated with the user data, and (iii) store the user data as part of the metadata for the one or more cloud resources.
However, Raj, in an analogous art, teaches them as can be seen in the in-line citations below:
wherein the cyber security system is further communicatively coupled to (i) receive user data, (ii) determine one or more cloud resources of the plurality of cloud resources associated with the user data, and (iii) store the user data as part of the metadata for the one or more cloud resources (A proposed system tracks user and entity behavior under 3 categories—time, count, and pattern. An event is composed of different fields that describe it. For example, a log on event could have different fields like username, hostname, log on time, log on type, etc. – [0026]).
This combination would have been obvious to one of ordinary skill in the art because of the exility mentioned benefit in Raj of detecting compromised user accounts in cloud applications. Raj notes “A User and Entity Behavior Analysis (UEBA) system helps build a behavioral profile of users and entities in an organization and assigns a risk score when the behavior of a user or entity deviates from the normal. This intrusion detection system helps identify compromised accounts, data exfiltration, and insider threats and can serve both as a diagnostic tool and an early warning system” [0024]. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date to incorporate the process of tracking user and entity behavior in order to identify compromised accounts to the overall cloud network topology mapping system of Jegarajan.
As per claim 18 – Jegarajan teaches a non-transitory storage medium including software that, upon execution by a processor, performs operations comprising (The software module(s) may be stored in any type of a suitable non-transitory storage medium, or transitory storage medium (e.g., electrical, optical, acoustical or other form of propagated signals such as carrier waves, infrared signals, or digital signals) – [0021]): identifying a plurality of cloud resources within a customer cloud environment; collecting metadata associated with the plurality of cloud resources from a cloud provider of the customer cloud environment; augmenting the metadata associated with the plurality of cloud resources based on (i) metadata associated with network traffic data being monitored by sensors deployed within the customer cloud environment (In some embodiments, the communication interface logic 214, upon execution by one or more processors, performs operations as discussed herein pertaining to querying a controller for construct metadata, receiving the requested construct metadata and receiving the network data from one or more gateways managed by the controller. In some embodiments, the received construct metadata and network data may be stored in the construct metadata database 220 and the network data database 222 (which may be separate or a combined database) – [0054]; The communication interface logic receiving construct metadata and storing it in the construct metadata database).
and (iii) metadata associated with flow log data (By querying the controller for construct metadata and receiving network data from one or more gateways, the topology system logic may generate the exemplary visualizations described above, and those shown in the accompanying drawings, that illustrate the flow of network traffic associated with one or more tagged constructs – [0018]).
and automatically generating visualizations of one or more cloud architectures associated with the plurality of cloud resources based on the metadata after the collecting and augmenting of the metadata (By querying the controller for construct metadata and receiving network data from one or more gateways, the topology system logic may generate the exemplary visualizations described above, and those shown in the accompanying drawings, that illustrate the flow of network traffic associated with one or more tagged constructs – [0018]).
It does not teach the following limitation:
(ii) metadata associated with user data.
However, Raj, in an analogous art, teaches it as can be seen in the in-line citation below:
(ii) metadata associated with user data (A proposed system tracks user and entity behavior under 3 categories—time, count, and pattern. An event is composed of different fields that describe it. For example, a log on event could have different fields like username, hostname, log on time, log on type, etc. – [0026]).
Claim(s) 16-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Jegarajan in view of Levin further in view of Guha further in view of Raj.
As per claim 16 –The combination of Jegarajan, Levin and Guha teach the computerized method of claim 15. It does not teach the following limitation:
further comprising: receiving user data; determining one or more cloud resources of the plurality of cloud resources associated with the user data; and storing the user data as part of the metadata for the one or more cloud resources.
However, Raj, in an analogous art, teaches it as can be seen in the in-line citation below:
further comprising: receiving user data; determining one or more cloud resources of the plurality of cloud resources associated with the user data; and storing the user data as part of the metadata for the one or more cloud resources (A proposed system tracks user and entity behavior under 3 categories—time, count, and pattern. An event is composed of different fields that describe it. For example, a log on event could have different fields like username, hostname, log on time, log on type, etc. – [0026]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSEPH MAXEN LANE whose telephone number is (571)272-8027. The examiner can normally be reached M-F from 7:30 A.M. - 5 P.M..
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, April Y. Blair can be reached at (571) 270-1014. 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.
/JOSEPH MAXEN LANE/Examiner, Art Unit 2196
/HIREN P PATEL/Primary Examiner, Art Unit 2196
Prosecution Insights