DETAILED ACTION
This Office action is in response to Applicant's amendment and request for
reconsideration filed on April 10, 2026.
Claims 1-3, 6-12, 15-20, and 24-27 are pending.
Response to Arguments
Applicant's arguments filed April 10, 2026, with respect to the previous 35 U.S.C. §112(a) rejection, have been fully considered but they are not persuasive.
For similar reasons previously of record, the specification fails to describe the multi-step process of:
“for each monitored metric, … generating a recommendation to expand or reduce a number of execution environments for the fxDeviceApp or fxCloudApp components;
selecting, in accordance with policies configured in an fxManager, a resulting desired number of execution environments based on the recommendations;
in response to the resulting desired number exceeding a current number, initiating, by the dRS deployment of additional execution environments for the fxDeviceApp or fxCloudApp components.”
As opposed to the multi-step process, it appears from Fig. 17A-17B, ¶0091, and Table 8, that the system described by Applicant’s specification simply makes a cloud expansion or reduction decision based on a policy-defined threshold condition being satisfied, which may be based on CPU utilization (see ¶0091), memory utilization (see ¶0091), or traffic load (see Table 8), and thereafter requests the fxCloudApp-0/VM Master (see Fig. 17A-17B) to launch or destroy a VM (i.e., an execution environment) based on the cloud expansion or reduction decision. However, there is nothing in the specification that corresponds to the step of “for each monitored metric, … generating a recommendation to expand or reduce a number of execution environments”, let alone, “selecting, in accordance with policies configured in an fxManager, a resulting desired number of execution environments based on the recommendations” (i.e., in the aggregate), and “in response to the resulting desired number exceeding a current number, initiating, by the dRS deployment of additional execution environments for the fxDeviceApp or fxCloudApp components.”
Even if, arguendo, the terms “recommendation” and “decision” were synonymous, as appears to be suggested by Applicant’s remarks (i.e., “generates a recommendation or decision”, see pp. 15 of Applicant’s remarks), there is nothing in the “Cloud Breathing disclosure” to support “selecting, in accordance with policies configured in an fxManager, a resulting desired number of execution environments based on the [decisions]…” and the further step of considering whether “the resulting desired number [exceeds] a current number…”.
In other words, Fig. 17A-17B, show a single decision being made based on a policy-defined threshold condition for a particular metric (e.g., “VM Overloaded?” or “VMs Under-Loaded?”). The system then makes an appropriate request to the fxCloudApp-0/VM Master to automatically add a VM or destroy a VM according to the decision. However, there is nothing in Fig. 17A-17B, ¶0091, and Table 8 to suggest the request to the fxCloudApp-0/VM Master is preceded by selecting “a resulting desired number of execution environments” based on considering a plurality of individual metric decisions/recommendations (i.e., “selecting, …, a resulting desired number of execution environments based on the recommendations…”), let alone considering whether “the resulting desired number [exceeds] a current number…”.
With respect to claims 6 and 15, although the specification supports initiating the deployment of additional execution environments based on “CPU load on a particular fxDevice (or a target area)”, the specification fails to support the limitation of “initiating the deployment of additional execution environments based on both i) resource consumption at a particular fxDeviceApp or fxCloudApp execution environment associated with a particular newtork element and ii) resource consumption for a target area comprising multiple network elements, in accordance with policies configured in the fxManager.”
Claim Objections
Claim 27 is objected to because of the following informalities: There is a typographical error in the claim.
For the purpose of this office action, the Examiner is interpreting the claim to read:
“The non-transitory computer-readable medium of claim 19, [[,]] wherein the policy-defined threshold condition…”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
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.
Claims 1-3, 6-12, 15-20, and 24-27 are 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.
For similar reasons previously of record and also noted above (see “Response to Arguments” above), as per claims 1, 10, and 19 the specification fails to describe 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, the steps of:
“for each monitored metric, … generating a recommendation to expand or reduce a number of execution environments for the fxDeviceApp or fxCloudApp components;
selecting, in accordance with policies configured in an fxManager, a resulting desired number of execution environments based on the recommendations;
in response to the resulting desired number exceeding a current number, initiating, by the dRS deployment of additional execution environments for the fxDeviceApp or fxCloudApp components.”
As opposed to the multi-step process, it appears from Fig. 17A-17B, ¶0091, and Table 8, that the system described by Applicant’s specification simply makes a cloud expansion or reduction decision based on a policy-defined threshold condition, which may include CPU utilization, memory utilization (see ¶0091), and/or traffic load (see Table 8), and thereafter requests the fxCloudApp-0/VM Master (see Fig. 17A-17B) to launch or destroy a VM (i.e., an execution environment) according to the decision. However, there is nothing in the specification that corresponds to the step of “generating a recommendation”, let alone, “selecting, in accordance with policies configured in an fxManager, a resulting desired number of execution environments based on the recommendations; and “in response to the resulting desired number exceeding a current number, initiating, by the dRS deployment of additional execution environments for the fxDeviceApp or fxCloudApp components.”
As per claims 6 and 15, the specification fails to describe 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, the step of:
“initiating the deployment of additional execution environments based on both i) resource consumption at a particular fxDeviceApp or fxCloudApp execution environment associated with a particular network element and ii) resource consumption for a target area comprising multiple network elements, in accordance with policies configured in the fxManager.”
Claims not specifically addressed are rejected under 35 U.S.C. §112(a) based on their dependency to one of the claims noted above.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-3, 6-12, 15-20, and 24-27 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claim 1, 10, and 19, it is unclear if the different “policies” introduced in the claim (i.e., “selecting in accordance with policies configured in an fxManager” and “applying traffic policies to the traffic by the policy enforcement based on policies received from policy logic”) are separate and distinct. For the purpose of this office action the Examiner is interpreting the claim to read:
“…applying traffic policies to the traffic by the policy enforcement , the traffic policies received from policy logic”.
Claims not specifically addressed are rejected under 35 U.S.C. §112(b) based on their dependency to one of the claims noted above.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 6, 9-12, 15, 18, 19, and 26-27 are rejected under 35 U.S.C. 103 as being unpatentable over Kunze et al. (US 2013/0054776)(“Kunze”), Samovoskiy et al. (US 2010/0115606) (“Samovoskiy”), Adams et al. (US 8,693,344)(“Adams”), in further view of Casado et al. (US 2010/0257263)(“Casado”).
As per claim 1, Kunze teaches a computer-implemented method for automatically adjusting a number of application instances in a distributed software-defined network (see abstract), comprising:
executing, on a plurality of network elements (i.e., Cloud 130, see Fig. 1A, comprising multiple hosts 110, 120, etc.), a set of fxDeviceApp and fxCloudApp components (i.e., first/second tiered components) associated with a distributed application (i.e., web application, see ¶0014);
monitoring, by a distributed resource service (dRS) (i.e., policy manager 230 in combination with monitoring subsystem 222, see Fig. 2, and ¶0036-¶0037), a plurality of distinct usage metrics including (i) CPU utilization or memory utilization associated with resource consumption by the fxDeviceApp or fxCloudApp components (i.e., “CPU utilization” see ¶0036, and/or “average CPU load”, see ¶0039) and (ii) traffic load measured by the fxCloudApp (e.g., “traffic”, see ¶0036, and/or “requests per second”, see ¶0039);
for each monitored metric, comparing, by the dRS, the metric to a corresponding policy-defined threshold condition (i.e., “Policy manager 230 compares monitoring data 224 (including historical monitoring data and/or current monitoring data) to one or more policies 234”, see ¶0037) and generating a recommendation to expand or reduce a number of execution environments for the fxDeviceApp or fxCloudApp components (i.e., “Policy manager 230 may trigger scaling events 238 when scaling policies 234 are violated”, see ¶0038);
selecting, in accordance with policies configured in an fxManager (e.g., “functionality for managing the application 240 and components 220”, see ¶0035, read as an “fxManager”, and ¶0033, where the network administrator may modify/configure various policies [impliedly through the functionality for managing the application 240 and components 220], including deployment constraint(s), see ¶0040, and/or first and second scaling policies, see ¶0039), a resulting desired number of execution environments based on the recommendations (see ¶0041, i.e., “the event manager 226 would determine whether to add a new node to run another copy of the first platform instance in accordance with the first scaling event or whether to add a new node to nm another copy of the second platform instance in accordance with the second scaling event”);
in response to the resulting desired number exceeding a current number (see ¶0040, i.e., “a deployment constraint may specify that no more than 5 nodes may be used for the application deployment, and currently there may be 4 nodes running for the application deployment”), initiating, by the dRS deployment of additional execution environments for the fxDeviceApp or fxCloudApp components (see ¶0041, i.e., “messaging manager 228 then sends a message to the cloud controller to cause the cloud controller to provision a new node”);
establishing … communication channels between the additional execution environments and other components of the distributed application (see ¶0042, i.e., “the cluster manager 233 may also make sure that the other nodes in the cluster know about the new node”, also see ¶0043, which further explains the use of connection points, i.e., channels, for communication with the new node).
As per claim 1, Kunze does not expressly teach establishing secure communication channels between the additional execution environments and other components of the distributed application using a virtual fabric (fxVF).
Nevertheless, in the same art of computer network management, Samovskiy teaches the use and benefit of using a virtual fabric comprising secure channels (i.e., VPNs) to establish communication between nodes in a cloud environment (see ¶0016, “[t]hese virtual networks are formed through one or more VPN connections, which overlay the existing cloud network”).
It would have been obvious to a person having ordinary skill in the art, prior to the earliest effective filing date of the claimed invention, to modify the teachings of Kunze with the teachings of Samovskiy to utilize a virtual network comprising one or secure VPN connections to establish communication between nodes in the cloud networking environment of Kunze (see Fig. 1A, ref. 130). The obvious motivation for doing so would have been to improve security and fault tolerance (see for example, Samovoskiy ¶0064).
As per claim 1, the combination of Kunze and Samovoskiy does not further teach updating, under control of a switch controller, a flow information (FIB) of a virtual switch to direct traffic to the additional execution environments and applying traffic policies to the traffic by policy enforcement based on policies received from the policy logic.
Nevertheless, in the same art of computer network management, Adams teaches controlling the flow of traffic through a network through a controller server that controls a network of switches (see abstract), wherein, under control the controller server, a flow information (FIB) of a switch (i.e., flow tables, see Fig. 2, ref. 28, and col. 6, lines 4-46) is updated to direct traffic to an additional execution environment (e.g., if a new host is detected, see col. 5, lines 6-30) and applying traffic policies to the traffic by policy enforcement based on policies received from the policy logic (i.e., controller server 18 may be used to implement network configuration rules, see col. 5, lines 31-36, Fig. 20, and col. 22, lines 8-55).
It would have been obvious to a person having ordinary skill in the art, prior to the earliest effective filing date of the claimed invention, to implement a similar controller and network of switches for making forwarding decisions for packets communicated in the network of Kunze. The obvious motivation for doing so would have been to provide improved traffic controlling capabilities (see Adams, col. 1, lines 44-47).
Finally, although Adams invention is described with respect to physical network switches as opposed to virtual switches as claimed, nevertheless, the use and benefit of virtual switches was well known in the art prior to the earliest effective filing date of the claimed invention (see for example Casado, ¶0003-0006).
It would have been obvious to a person having ordinary skill in the art, prior to the earliest effective filing date of the claimed invention, to implement the invention taught by Adams with virtual switches as opposed to, or in addition to, physical switches. The obvious motivation for implementing the system using virtual switches would have been to decouple the switch processing from the underlying physical hardware (see for example Casado, ¶0004), thus improving configurability.
As per claim 2, Kunze further teaches wherein the execution environments comprise containers or virtual machines managed by the fxManager (i.e., VMs, see Fig. 1A).
As per claim 3, Kunze further teaches, in response to determining that the usage metrics fall below a lower threshold, initiating deactivation or destruction of one or more existing execution environments associated with the fxDeviceApp or fxCloudApp components (i.e., a policy causes a scale down event, see ¶0033).
As per claim 6, Kunze further teaches wherein the dRS initiates the deployment of the additional execution environments based on both (i) resource consumption at a particular fxDeviceApp or fxCloudApp execution environment associated with a particular network element (see ¶0037, where policies can be set for individual components, i.e., fxDeviceApp or fxCloudApp) and (ii) aggregate resource consumption for a target area comprising multiple network elements (provisioning group 360/370, see Fig. 3), in accordance with policies configured in the fxManager (i.e., “if provisioning group 360 experiences heavy load…”, see ¶0050).
As per claim 9, Kunze further teaches wherein resource scaling is performed independently for fxDeviceApp and fxCloudApp components based on distinct performance criteria (see ¶0037, where policies can be set for individual components, i.e., fxDeviceApp or fxCloudApp).
Claims 10-12, 15, 18, and 19 are rejected under the same rationale as claims 1-3, 6, and 9 since they recite substantially identical subject matter. Any differences between the claims do not result in patentably distinct claims and all of the limitations are taught by the above cited art.
As per claims 26 and 27, Kunze further teaches wherein the policy-defined threshold condition is configurable by an administrator via the fxManager (see ¶0033, where the network administrator may modify/configure various policies, which is impliedly through the “functionality for managing the application 240 and components 220”, see ¶0035, i.e., fxManager) and includes at least one of (i) an upper threshold that triggers expansion of execution environments (i.e., “scale up”, see ¶0039) or (ii) a lower threshold that triggers reduction of execution environments (i.e., “scale down”, see ¶0039).
Claims 7-8, 16-17, 20, and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Kunze, Samovoskiy, Adams, and Casado, in further view of Hayes et al. (US 2013/0133045)(“Hayes”).
As per claim 7, Kunze fails to teach wherein the application instances are preconfigured with a security certificate validated prior to activation.
Nevertheless, in the same art of distributed application management, Hayes teaches the use of a cryptographically signed identities (e.g., x.509 certificates) associated with resources/execution environment (i.e., application instances) that are validated by a trust director (see Fig. 1, ref. 16) prior to activation (i.e., prior to being made available or added to the pool of authenticated network resources, see ¶0153).
It would have been obvious to a person having ordinary skill in the art, prior to the earliest effective filing date of the claimed invention, to modify the teachings of Kunze and Dyke with the teachings of Hayes for preconfiguring application instances/execution environments with a security certificate validated prior to activation. The obvious motivation for doing so would have been to promote network integrity.
As per claim 8, Kunze fails to teach wherein each fxDeviceApp and fxCloudApp component is associated with a cryptographically signed identity and a policy-enforced access level managed by the fxManager.
Nevertheless, first, in the same art as noted above, Hayes teaches the use of a cryptographically signed identities (e.g., x.509 certificates) associated with resources/execution environment that are validated by a trust director (see Fig. 1, ref. 16) prior to activation (i.e., prior to being made available or added to the pool of authenticated network resources, see ¶0153).
It would have been obvious to a person having ordinary skill in the art prior to the earliest effective filing date of the claimed invention to modify the teachings of Kunze and Dyke with the teachings of Hayes, for preconfiguring resources/execution environment, on which application components (e.g., fxDeviceApp and fxCloudApp) may be deployed, with a security certificate validated prior to activation (i.e., “each fxDeviceApp and fxCloudApp component is associated with a cryptographically signed identity”). The obvious motivation for doing so would have been to promote network integrity.
Furthermore, in the same art as noted above, Adams teaches the enforcement of policies restricting access to certain services managed a controller server (see col. 12, lines 9-19, read as policy-enforced access level management).
Similarly, it would have been obvious to a person having ordinary skill in the art, prior to the earliest effective filing date of the clamed invention, to configure fxManager (i.e., “the functionality for managing the application 240 and components 220”, see Kunze ¶0035) to restrict access to certain services (i.e., fxDeviceApp and fxCloudApp components). The obvious motivation for doing so would have been to provide enhanced security.
Claims 16-17 are rejected under the same rationale as claims 7-8 since they recite substantially identical subject matter. Any differences between the claims do not result in patentably distinct claims and all of the limitations are taught by the above cited art.
As per claims 20 and 24, Kunze further teaches bringing a new node online only after i) “all relevant software is installed on the new node”, see ¶0042, and ii) communication channels are established with the new node (i.e., “other nodes in the in the cluster know about the new node”, see ¶0042, also see ¶0043, which further explains the use of connection points, i.e., channels, for communication with the new node).
As noted above, Kunze fails to teach where bringing the new node online comprises validating a security certificate or cryptographically signed identity associated with the new node (i.e., “newly deployed execution environment” as claimed).
Nevertheless, in the same art as noted above, Hayes teaches the use of a cryptographically signed identities (e.g., x.509 certificates) associated with resources/execution environment that are validated by a trust director (see Fig. 1, ref. 16) prior to activation (i.e., prior to being made available or added to the pool of authenticated network resources, see ¶0153).
The same motivation for combining Kunze and Hayes in claims 7 and 8 applies equally well to claims 20 and 24.
Furthermore, as noted above, Kunze fails to teach where establishing communication channels comprises establishing the secure communication channels using the virtual fabric (fxVF).
Nevertheless, in the same art as noted above, Samovskiy teaches the use and benefit of using a virtual fabric comprising secure channels (i.e., VPNs) to establish communication between nodes in a cloud environment (see ¶0016, “[t]hese virtual networks are formed through one or more VPN connections, which overlay the existing cloud network”).
The same motivation for combining Kunze and Samovksiy in claim 1 applies equally well to claims 20 and 24.
Finally, Kunze fails to teach following the addition of the new node updating the flow information base (FIB) of the virtual switch enabling traffic to the newly deployed execution environment.
Nevertheless, in the same art as noted above, Adams teaches controlling the flow of traffic through a network through a controller server that controls a network of switches (see abstract), wherein, under control the controller server, a flow information (FIB) of a switch (i.e., flow tables, see Fig. 2, ref. 28, and col. 6, lines 4-46) is updated to direct traffic to a newly deployed execution environment (e.g., if a new host is detected, see col. 5, lines 6-30).
In addition, although Adams invention is described with respect to physical network switches as opposed to virtual switches as claimed, nevertheless, the use and benefit of virtual switches was well known in the art prior to the earliest effective filing date of the claimed invention (see for example Casado, ¶0003-0006).
The same motivation for combining Kunze and Adams/Casado in claim 1 applies equally well to claims 20 and 24.
Allowable Subject Matter
Claim 25 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is an examiner’s statement of reasons for allowance:
Though rejected under 35 U.S.C. §112(a) and §112(b) based on dependency (see Claim Rejections - 35 USC § 112), the prior art does not teach or render obvious, before the earliest effective filing date of Applicant’s claimed invention, in the specific combinations and manner recited within the claims, the further features of:
“…wherein the establishing of the secure communication channels comprises creating, by the fxCloudApp, secure tunnels for message exchange between the additional execution environments and at least one of the fxManager or another fxCloudApp using the virtual fabric (fxVF)”.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRENDAN HIGA whose telephone number is (571)272-5823. The examiner can normally be reached Monday - Friday 8:30 AM - 5:00 PM.
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, James Hwang can be reached at 571-272-4036. 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.
/BRENDAN Y HIGA/Primary Examiner, Art Unit 2447
Prosecution Insights