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 .
This office Action is in response to Application 18827129 filed on 09/06/2024. Claims 1 and 11 are independent claims. Claims 1-20 have been examined and are pending in this application. This Office Action is made Non-Final.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 09/06/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered 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.
Claims 1, 4-11, and 14-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-3, 5-7, 9-12, 14-16, and 18 of U.S. Patent No. 12,111,918. They are not patentably distinct from each other because the claims of the instant application are anticipated by the reference claims.
Claims 1, 4-11, and 14-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-3, 5-7, 9-12, 14-16, and 18 of U.S. Patent No. 12,111,918. Although the claims at issue are not identical, they are not patentably distinct from each other because Claims 1, 4-11, and 14-20 of the instant application are anticipated by claims 1-3, 5-7, 9-12, 14-16, and 18 of the US Patent No. 12,111,918, respectively (refer to the comparison table below for detail).
Instant Application 18/827,129
US patent No. 12,111,918
Claim 1. A method comprising:
operating, by a microservice host, a plurality of microservices, the plurality of microservices performing a plurality of system level activities including generating a plurality of system calls to an operating system kernel of the microservice host;
generating, by the microservice host, system level activity data from the plurality of system level activities;
transmitting, by the microservice host, the system level activity data to a microservice evaluator,
causing the microservice evaluator to evaluate the system level activity data to identify normal system level activities and abnormal system level activities, and
generate a plurality of security policies corresponding to the plurality of microservices;
receiving, by the microservice host, the plurality of security policies or a plurality of updated microservice images comprising the plurality of security policies, the plurality of security policies comprising a plurality of permitted system level activities and a plurality of non-permitted system level activities; and
allowing permitted system level activities of the plurality of system level activities and preventing non-permitted system level activities of the plurality of system level activities.
Claim 1. A method comprising:
receiving, by a microservice evaluator, from a microservice host, system level activity data corresponding to a plurality of microservices operating on the microservice host, the microservice evaluator being different from, and communicatively coupled to, the microservice host;
training, by the microservice evaluator, a plurality of machine learning models using the system level activity data or a derivative thereof as training data, wherein each machine learning model corresponds to a particular microservice of the plurality of microservices operating on the microservice host;
determining, by the microservice evaluator, using the plurality of machine learning models corresponding to the plurality of microservices and the system level activity data, a plurality of sets of normal system level activities and abnormal system level activities;
determining, by the microservice evaluator, a plurality of security policies corresponding to the plurality of microservices, wherein each security policy comprises a plurality of permitted system level activities and a plurality of non-permitted system level activities;
providing, by the microservice evaluator, to a microservice orchestrator, the plurality of security policies, wherein the microservice orchestrator generates one or more configuration files corresponding to the plurality of security policies and deploys the one or more configuration files to the plurality of microservices operating on the microservice host; and
transmitting, by the microservice evaluator, an instruction to the microservice orchestrator, wherein in response to receiving the instruction, the microservice orchestrator identifies a plurality of microservice owners corresponding to the plurality of microservices and transmits one or more messages to one or more microservice owners of the plurality of microservice owners indicating a change in one or more security policies of the plurality of security policies.
11. A microservice host comprising:
a processor; and a non-transitory computer readable medium coupled to the processor, the non-transitory computer readable medium comprising code, executable by the processor for implementing a method comprising:
operating a plurality of microservices, the plurality of microservices performing a plurality of system level activities including generating a plurality of system calls to an operating system kernel of the microservice host;
generating system level activity data from the plurality of system level activities;
transmitting the system level activity data to a microservice evaluator,
causing the microservice evaluator to evaluate the system level activity data to identify normal system level activities and abnormal system level activities and generate a plurality of security policies corresponding to the plurality of microservices;
receiving the plurality of security policies or a plurality of updated microservice images comprising the plurality of security policies, the plurality of security policies comprising a plurality of permitted system level activities and a plurality of non-permitted system level activities; and
allowing permitted system level activities of the plurality of system level activities and preventing non-permitted system level activities of the plurality of system level activities.
10. A microservice evaluator comprising:
a processor; and a non-transitory computer readable medium coupled to the processor, the non-transitory computer readable medium comprising code, executable by the processor for implementing a method comprising:
receiving, from a microservice host, system level activity data corresponding to a plurality of microservices operating on the microservice host, the microservice evaluator being different from, and communicatively coupled to, the microservice host;
training a plurality of machine learning models using the system level activity data or a derivative thereof as training data, wherein each machine learning model corresponds to a particular microservice of the plurality of microservices operating on the microservice host;
determining using the plurality of machine learning models corresponding to the plurality of microservices and the system level activity data, a plurality of sets of normal system level activities and abnormal system level activities;
determining a plurality of security policies corresponding to the plurality of microservices, wherein each security policy comprises a plurality of permitted system level activities and a plurality of non-permitted system level activities;
providing to a microservice orchestrator, the plurality of security policies, wherein the microservice orchestrator generates one or more configuration files corresponding to the plurality of security policies and deploys the one or more configuration files to the plurality of microservices operating on the microservice host; and
transmitting an instruction to the microservice orchestrator, wherein in response to receiving the instruction, the microservice orchestrator identifies a plurality of microservice owners corresponding to the plurality of microservices and transmits one or more messages to one or more microservice owners of the plurality of microservice owners indicating a change in one or more security policies of the plurality of security policies.
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 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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.
Claims 1, 4-5, 11, and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over STOPEL et al. (“STOPEL,” US 20170116412, published on 04/27/2017) in view of GAO et al. (“GAO,” CN 108683557 B, filed on 04/28/2018).
Regarding Claim 1;
STOPEL discloses a method comprising:
operating, by a microservice host, a plurality of microservices, the plurality of microservices performing a plurality of system level activities including generating a plurality of system calls to an operating system kernel of the microservice host (par 0099; software container include a micro-service; par 0005; software containers enable operating-system-level virtualization in which the OS kernel allows the existence of multiple isolated software containers; par 0033; performed by the respective application container when executed. In an embodiment, a security profile include at least one of: a list of allowed (whitelist) system calls, a list of permissible network actions, a list of permissible filesystem actions; par 0045; the detector container is configured to identify calls to procedures. Such calls are collectively referred to hereinafter as “callable units” or a “callable unit”; par 0065; the security profile is generated for the container image, while the security profile lists the system call “close”, there is no violation of the profile. If the captured system call “chdir” is not included in the profile, a violation of the profile is determined);
generating, by the microservice host, system level activity data from the plurality of system level activities (par 0099; software container include a micro-service; par 0045; the detector container is configured to identify calls to procedures; par 0065; the security profile is generated for the container image, while the security profile lists the system call “close”, there is no violation of the profile. If the captured system call “chdir” is not included in the profile, a violation of the profile is determined);
the system level activity data to a microservice evaluator, causing the microservice evaluator to evaluate the system level activity data to identify normal system level activities and abnormal system level activities (par 0065; system call triggered by the execution of the APP container is captured and compared to the allowable system calls defined in the respective profile. For example, assuming that the security profile is generated for the container image, while the security profile lists the system call “close”, there is no violation of the profile. If the captured system call “chdir” is not included in the profile, a violation of the profile is determined), and
generate a plurality of security policies corresponding to the plurality of microservices (par 0033; performed by the respective application container when executed. In an embodiment, a security profile include at least one of: a list of allowed (whitelist) system calls, a list of permissible network actions, a list of permissible filesystem actions; par 0047; upon detecting callable units in the container image, each such callable unit is mapped to one or more system calls. The mapping is performed using a preconfigured mapping table stored [] a table that initially includes a mapping to a Linux system call “chdir”. This system call would be removed from the table if reported as vulnerable. In an embodiment, the vulnerable system calls are not included in the mapping table. Table 1 demonstrates an example mapping table for mapping between some node.js callable units and some Linux system calls);
receiving, by the microservice host, the plurality of security policies or a plurality of updated microservice images comprising the plurality of security policies, the plurality of security policies comprising a plurality of permitted system level activities and a plurality of non-permitted system level activities (par 0047; upon detecting callable units in the container image, each such callable unit is mapped to one or more system calls. The mapping is performed using a preconfigured mapping table stored, for example, in the database. In an embodiment, the mapping table includes, for each runtime process (and its version), a list of callable units. Each callable unit includes one or more matching system calls for each type of OS (e.g., Linux, Windows®, etc.). The mapping table can be updated upon release of new runtime process version and/or operating system. The mapping table can be updated when vulnerable system calls are reported. For example, a table that initially includes a mapping to a Linux system call “chdir”. This system call would be removed from the table if reported as vulnerable. In an embodiment, the vulnerable system calls are not included in the mapping table. Table 1 demonstrates an example mapping table for mapping between some node.js callable units and some Linux system calls; par 0065; system call triggered by the execution of the APP container is captured and compared to the allowable system calls defined in the respective profile. For example, assuming that the security profile is generated for the container image, while the security profile lists the system call “close”, there is no violation of the profile. If the captured system call “chdir” is not included in the profile, a violation of the profile is determined); and
allowing permitted system level activities of the plurality of system level activities and preventing non-permitted system level activities of the plurality of system level activities (par 0044; performed by the respective software . The security profile include, but is not limited to, a list of allowed system calls, a list of permissible network actions, a list of permissible filesystem actions, signatures of executable files of spawned processes; par 0065; system call triggered by the execution of the APP container is captured and compared to the allowable system calls defined in the respective profile. For example, assuming that the security profile is generated for the container image, while the security profile lists the system call “close”, there is no violation of the profile. If the captured system call “chdir” is not included in the profile, a violation of the profile is determined).
STOPEL discloses the system level activity data to a microservice evaluator, causing the microservice evaluator to evaluate the system level activity data to identify normal system level activities and abnormal system level activities as recited above, but do not explicitly disclose transmitting, by the microservice host, the system level activity data to a microservice evaluator.
However, in an analogous art, GAO discloses micro-service health degree evaluation system/method that includes:
transmitting, by the microservice host, the system level activity data to a microservice evaluator (GAO: page 3, pars 10-11; for distributing the request to the service node according to the preset balancing strategy; Monitoring module: for collecting the monitoring data sent by the service module and calculating the instance health value, environment health value and service health value, then sending the calculated health value to the node management module).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of GAO with the method/system of STOPEL to include transmitting, by the microservice host, the system level activity data to a microservice evaluator. One would have been motivated to determining the instance health value of each service instance according to the request error ratio of each service instance in the service (GAO: abstract).
Regarding Claim 4;
The combination of STOPEL and GAO disclose the method of claim 1,
STOPEL discloses wherein the plurality of microservices are implemented using a plurality of software containers or a plurality of virtual machines or a combination thereof (STOPEL: par 0099; software container include a micro-service; par 0005; software containers enable operating-system-level virtualization in which the OS kernel allows the existence of multiple isolated software containers).
Regarding Claim 5;
The combination of STOPEL and GAO disclose the method of claim 1,
STOPEL discloses wherein the plurality of permitted system level activities correspond to the normal system level activities and the plurality of non-permitted system level activities correspond to the abnormal system level activities (STOPEL: par 0044; performed by the respective software . The security profile include, but is not limited to, a list of allowed system calls, a list of permissible network actions, a list of permissible filesystem actions, signatures of executable files of spawned processes; par 0065; system call triggered by the execution of the APP container is captured and compared to the allowable system calls defined in the respective profile. For example, assuming that the security profile is generated for the container image, while the security profile lists the system call “close”, there is no violation of the profile. If the captured system call “chdir” is not included in the profile, a violation of the profile is determined).
Regarding Claim 11;
This Claim recites a microservice that perform the same steps as method of Claim 1, and has limitations that are similar to Claim 1, thus are rejected with the same rationale applied against claim 1.
Regarding Claim 14;
This Claim recites a microservice that perform the same steps as method of Claim 4, and has limitations that are similar to Claim 4, thus are rejected with the same rationale applied against claim 4.
Regarding Claim 15;
This Claim recites a microservice that perform the same steps as method of Claim 5, and has limitations that are similar to Claim 5, thus are rejected with the same rationale applied against claim 5.
Claims 2-3 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over STOPEL et al. (US 20170116412) in view of GAO et al. (CN 108683557 B), and further in view of Hwang et al. (“Hwang,” US 20180025160, published on 01/25/2018).
Regarding Claim 2;
The combination of STOPEL and GAO disclose the method of claim 1,
STOPEL discloses wherein the system level activity data is first system level activity data and wherein the method further comprises: additionally operating, by the microservice host, the plurality of microservices, the plurality of microservices performing a second plurality of system level activities including generating a second plurality of system calls to the operating system kernel of the microservice host (STOPEL: 0005; software containers enable operating-system-level virtualization in which the OS kernel allows the existence of multiple isolated software containers; par 0044; performed by the respective software (e.g., the container). The security profile include, but is not limited to, a list of allowed system calls, a list of permissible network actions, a list of permissible filesystem actions, signatures of executable files of spawned processes; par 0065; the security profile is generated for the container image, while the security profile lists the system call “close”, there is no violation of the profile. If the captured system call “chdir” is not included in the profile, a violation of the profile is determined; par 0077; an event indicating that a container image should be scanned is received. Such an event can be received from a continuous integration system, an image registry, and the like. The event designate a specific container image or a group of images (each of which identified by their unique identifier) and the source of the images to be scanned [] further, multiple container images and APP containers can be processed in parallel);
generating, by the microservice host, second system level activity data from the second plurality of system level activities (STOPEL: par 0077; the event designate a specific container image or a group of images (each of which identified by their unique identifier) and the source of the images to be scanned [] further, multiple container images and APP containers can be processed in parallel; par 0065; the security profile is generated for the container image, while the security profile lists the system call “close”, there is no violation of the profile. If the captured system call “chdir” is not included in the profile, a violation of the profile is determined).
GAO further discloses transmitting, by the microservice host, the second system level activity data to the microservice evaluator (GAO: page 3, pars 10-11; for distributing the request to the service node according to the preset balancing strategy; Monitoring module: for collecting the monitoring data sent by the service module and calculating the instance health value, environment health value and service health value, then sending the calculated health value to the node management module).
The motivation is the same that of claim 1 above.
The combination of STOPEL and GAO disclose the microservice as recited above, but do not explicitly disclose wherein the microservice evaluator generates a plurality of anomaly scores or a plurality of control instructions using a plurality of machine learning models and the second system level activity data, wherein the plurality of anomaly scores or the plurality of control instructions correspond to the plurality of microservices.
However, in an analogous art, Hwang discloses generating containers system/method that includes:
wherein the microservice evaluator generates a plurality of anomaly scores or a plurality of control instructions using a plurality of machine learning models and the second system level activity data, wherein the plurality of anomaly scores or the plurality of control instructions correspond to the plurality of microservices (Hwang: par 0069; risk values and the risk threshold, for example, may not be numeric but may instead be assigned letter grades, color codes; par 0081; the risk analysis comprises comparing a risk value calculated for the given container to a designated risk threshold. In response to the risk value calculated for the given container exceeding the designated risk threshold, one or more actions are simulated in the given container. A determination is made whether to accept or reject the given container responsive to the risk analysis and simulated actions).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Hwang with the method/system of STOPEL and GAO to include wherein the microservice evaluator generates a plurality of anomaly scores or a plurality of control instructions using a plurality of machine learning models and the second system level activity data, wherein the plurality of anomaly scores or the plurality of control instructions correspond to the plurality of microservices. One would have been motivated to compare a risk value calculated for the given container to a designated risk threshold, simulating one or more actions in the given container responsive to the risk value calculated for the given container exceeding the designated risk threshold, and determining whether to accept or reject (Hwang: abstract).
Regarding Claim 3;
The combination of STOPEL, GAO, and Hwang disclose the method of claim 2, further comprising:
Hwang discloses receiving, by the microservice host, from the microservice evaluator, the plurality of anomaly scores or the plurality of control instructions; and pausing or terminating, by the microservice host, one or more microservices of the plurality of microservices based on the plurality of anomaly scores or the plurality of control instructions (Hwang: par 0069; risk values and the risk threshold, for example, may not be numeric but may instead be assigned letter grades, color codes; par 0081; the risk analysis comprises comparing a risk value calculated for the given container to a designated risk threshold. In response to the risk value calculated for the given container exceeding the designated risk threshold, one or more actions are simulated in the given container. A determination is made whether to accept or reject the given container responsive to the risk analysis and simulated actions).
The motivation is the same that of claim 2 above.
Regarding Claim 12;
This Claim recites a microservice that perform the same steps as method of Claim 2, and has limitations that are similar to Claim 2, thus are rejected with the same rationale applied against claim 2.
Regarding Claim 13;
This Claim recites a microservice that perform the same steps as method of Claim 3, and has limitations that are similar to Claim 3, thus are rejected with the same rationale applied against claim 3.
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over STOPEL et al. (US 20170116412) in view of GAO et al. (CN 108683557 B), and further in view of Roche e al. (“Roche,” US 20190334789, filed on 04/26/2018).
Regarding Claim 6;
The combination of STOPEL and GAO disclose the method of claim 1,
STOPEL discloses wherein the system level activity data (STOPEL: par 0065; the security profile is generated for the container image, while the security profile lists the system call “close”, there is no violation of the profile. If the captured system call “chdir” is not included in the profile, a violation of the profile is determined);
The combination of STOPEL and GAO disclose system level activity data as recited above, but do not explicitly disclose data includes a plurality of audit logs, the plurality of audit logs generated by a microservice agent operating on the microservice host.
However, in an analogous art, Roche discloses microservices system/method that includes:
data includes a plurality of audit logs, the plurality of audit logs generated by a microservice agent operating on the microservice host (Roche: par 0029; microservice specification generation process mines the audit logs and/or transaction logs of the application to identify one or more interactions with a data store).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Hwang with the method/system of STOPEL and GAO to include data includes a plurality of audit logs, the plurality of audit logs generated by a microservice agent operating on the microservice host. One would have been motivated to parsing an audit log and/or a transaction log of the application to identify interactions with a data store; clustering the data store interactions using an unsupervised learning technique to identify patterns of usage of the data store (Roche: abstract).
Regarding Claim 16;
This Claim recites a microservice that perform the same steps as method of Claim 6, and has limitations that are similar to Claim 6, thus are rejected with the same rationale applied against claim 6.
Claims 7-10 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over STOPEL et al. (US 20170116412) in view of GAO et al. (CN 108683557 B), and further in view of Vyas et al. (“Vyas,” US 20180302283, filed on 04/17/2017).
Regarding Claim 7;
The combination of STOPEL and GAO disclose the method of claim 1,
STOPEL discloses wherein the plurality of security policies are provided to the microservice host by a microservice orchestrator, wherein the microservice orchestrator generates one or more configuration files corresponding to the plurality of security policies and deploys the one or more configuration files to the plurality of microservices operating on the microservice host (STOPEL: par 0099; software container include a micro-service; par 0005; software containers enable operating-system-level virtualization in which the OS kernel allows the existence of multiple isolated software containers; par 0033; performed by the respective application container when executed. In an embodiment, a security profile include at least one of: a list of allowed (whitelist) system calls, a list of permissible network actions, a list of permissible filesystem actions; par 0045; the detector container is configured to identify calls to procedures. Such calls are collectively referred to hereinafter as “callable units” or a “callable unit”; par 0065; the security profile is generated for the container image, while the security profile lists the system call “close”, there is no violation of the profile. If the captured system call “chdir” is not included in the profile, a violation of the profile is determined).
The combination of STOPEL and GAO disclose wherein the plurality of security policies are provided to the microservice host by a microservice orchestrator as recited above, but do not explicitly disclose wherein the microservice orchestrator generates one or more configuration files corresponding to the plurality of security policies and deploys the one or more configuration files to the plurality of microservices operating on the microservice host.
However, in an analogous art, Vyas discloses configuration recommendation for a microservice system/method that includes:
wherein the microservice orchestrator generates one or more configuration files corresponding to the plurality of security policies and deploys the one or more configuration files to the plurality of microservices operating on the microservice host (Vyas: par 0036; database management server analyzes configuration request and generates a query for a configuration that matches the set of conditions for submission to configuration data store. Database management server executes the query against configuration data store and searches the data store for the configuration that matches the set of conditions; par 0052; providing a configuration for a multitier microservice architecture. Configuration data stores one or more configurations, each configuration specifying one or more containers located at a first tier of a multitier microservice architecture and one or more containers located at a second tier of the multitier microservice architecture. Communications module receives configuration request from a user for a configuration that satisfies a set of conditions in cloud environment. Database management server searches configuration data store for a configuration that matches the set of conditions. Database management server store an entry that specifies a configuration and provides an indication of whether configuration satisfies one or more conditions).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Vyas with the method/system of STOPEL and GAO to include wherein the microservice orchestrator generates one or more configuration files corresponding to the plurality of security policies and deploys the one or more configuration files to the plurality of microservices operating on the microservice host. One would have been motivated to provide a configuration for a multitier microservice architecture includes receiving a configuration request from a user for a configuration that satisfies a set of conditions in a cloud environment (Vyas: abstract).
Regarding Claim 8;
The combination of STOPEL, GAO, and Vyas disclose the method of claim 7,
Vyas discloses wherein generating the one or more configuration files includes generating a plurality of updated microservice images corresponding to the plurality of microservices and sending the plurality of updated microservice images to the microservice host (Vyas: par 0052; providing a configuration for a multitier microservice architecture. Configuration data stores one or more configurations, each configuration specifying one or more containers located at a first tier of a multitier microservice architecture and one or more containers located at a second tier of the multitier microservice architecture. Communications module receives configuration request from a user for a configuration that satisfies a set of conditions in cloud environment. Database management server searches configuration data store for a configuration that matches the set of conditions. Database management server store an entry that specifies a configuration and provides an indication of whether configuration satisfies one or more conditions; par 0033; database management server continue to populate and update these table entries as time passes).
The motivation is the same that of claim 7 above.
Regarding Claim 9;
The combination of STOPEL, GAO, and Vyas disclose the method of claim 8,
wherein the one or more configuration files include information corresponding to providing updates or control instructions to the microservice host (Vyas: par 0052; providing a configuration for a multitier microservice architecture. Configuration data stores one or more configurations, each configuration specifying one or more containers located at a first tier of a multitier microservice architecture and one or more containers located at a second tier of the multitier microservice architecture. Communications module receives configuration request from a user for a configuration that satisfies a set of conditions in cloud environment. Database management server searches configuration data store for a configuration that matches the set of conditions. Database management server store an entry that specifies a configuration and provides an indication of whether configuration satisfies one or more conditions; par 0033; database management server continue to populate and update these table entries as time passes).
The motivation is the same that of claim 7 above.
Regarding Claim 10;
The combination of STOPEL, GAO, and Vyas disclose the method of claim 7,
STOPEL discloses wherein the microservice orchestrator identifies a plurality of microservice owners corresponding to the plurality of microservices and transmits one or more messages to one or more microservice owners of the plurality of microservice owners indicating a change in one or more security policies of the plurality of security policies (STOPEL: par 0055; executed by the APP container of the respective container image. For example, if a process “myCode” includes an instruction to open a port number, the security profile of the container image would designate “open port number as a permissible network action; par 0080; the contents of the container image are analyzed to generate a new security profile. Updating an existing security profile, the security profile is generated to include at least a list of allowed system calls, a list of permissible network actions, a list of permissible filesystem actions, signatures of executable processes, or a combination thereof; par 0081; the new or updated security profile is saved in a database indexed based on the respective container image identifier; par 0082; upon receiving an event indicative of instantiation, running, or both, of a new APP container).
Regarding Claim 17;
This Claim recites a microservice that perform the same steps as method of Claim 7, and has limitations that are similar to Claim 7, thus are rejected with the same rationale applied against claim 7.
Regarding Claim 18;
This Claim recites a microservice that perform the same steps as method of Claim 8, and has limitations that are similar to Claim 8, thus are rejected with the same rationale applied against claim 8.
Regarding Claim 19;
This Claim recites a microservice that perform the same steps as method of Claim 9, and has limitations that are similar to Claim 9, thus are rejected with the same rationale applied against claim 9.
Regarding Claim 20;
This Claim recites a microservice that perform the same steps as method of Claim 20, and has limitations that are similar to Claim 20, thus are rejected with the same rationale applied against claim 20.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHAO WANG whose telephone number is (313)446-6644. The examiner can normally be reached on Monday-Friday 7:30-4:30PM EST.
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, Luu Pham can be reached on (571)270-5002. 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 https://ppair-my.uspto.gov/pair/PrivatePair.
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.
/C.W./Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439