DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This action is in response to the communication filed on 06/09/2026. Claims 1-10 and 12-20 are pending in this application.
Response to Arguments
Applicant’s arguments filed 06/09/2026 have been fully considered but they are not persuasive. Applicant argues:
a.
Applicant states that “neither Miniswamy nor Li discloses or suggests at least ‘wherein obtaining the indication that the device is to act as the control node comprises obtaining an indication that a second device acting as a second control node within the decentralized hierarchical control plane has become nonoperational or impaired, and wherein managing the resources comprises managing the resources based on the indication that the second device acting as the second control node within the decentralized hierarchical control plane has become nonoperational or impaired’ as recited in claim 1. Applicant further states that “According to Muniswamy, however, Muniswamy teaches reassignment when a monitored parameter-such as processing-resource usage, memory usage, or disk usage-exceeds a predefined limit. That is best read as a load / threshold / capacity condition. Muniswamy is silent on that another controller has become nonoperational or impaired. That is, merely overloading may not cause a controller to be ‘nonoperational or impaired’ as recited in claim 1 (Reply, pp. 7-8).”
a.
Examiner respectfully disagrees. Applicant argues that Muniswamy only teaches reassignment when a monitored parameter exceeds a predefined threshold (e.g. processor usage, memory usage, or disk usage), and such a condition merely reflects overloading rather than a controller having “become nonoperational or impaired,” as recited in claim 1.
However, the examiner does not rely on Muniswamy as teaching reassignment solely in response to routine load balancing. Rather, Muniswamy teaches monitoring operational parameters of a controller and initiating reassignment of managed resources to a new master controller when those operational parameters indicate that the current master controller can no longer adequately perform its management functions. For example, excessive processor utilization, memory exhaustion, or disk resource exhaustion represent degraded operating conditions that impair the current master controller’s ability to continue performing its intended operations. A controller need not cease functioning entirely to be “impaired”. The ordinary meaning of “impaired” refers to degraded operational capability. Thus, a controller whose critical resources have reached predefined limits is reasonably considered impaired because its ability to reliably manage the assigned devices is adversely affected.
Therefore, Muniswamy is continuously considered to teach reassigning managed devices when a controller has become impaired.
b.
Applicant also states that “In addition, Muniswamy does not teach a ‘decentralized hierarchical control plane’ as recited in claim 1. Muniswamy's master controller cannot reasonably be interpreted as the claimed ‘decentralized hierarchical control plane.’ Muniswamy discloses a team of SDN controllers in which one controller is designated a master controller and other controllers are designated slave controllers for a region. The master controller is therefore merely one controller role within a controller team, not the broader control-plane architecture itself. By contrast, claim 1 expressly recites a ‘decentralized hierarchical control plane’ comprising ‘a plurality of control nodes in a decentralized hierarchy,’ thereby distinguishing the overall control-plane architecture from an individual device acting as a control node therein. Li's distributed control system likewise resides at the architectural level, including multiple root and regional controllers arranged in a hierarchy. Thus, even if Muniswamy 's master controller were viewed as one controller or node, it cannot reasonably be equated with the decentralized hierarchical control plane of Li, because doing so would improperly collapse a single controller role into an entire multi-controller hierarchical architecture (Reply, pp. 8-9).”
b.
Examiner respectfully disagrees. Applicant argues that Muniswamy’s master controller cannot reasonably be interpreted as the claimed “decentralized hierarchical control plane,” also arguing that the master controller is merely one controller role within a controller team rather than the overall control-plane architecture. However, this argument is not appropriate to the actual basis of the rejection.
The 35 USC § 103 rejection does not rely on Muniswamy as teaching the claimed “decentralized hierarchical control plane.” Rather, Muniswamy is relied upon for teaching obtaining, at a device, an indication that the device is to act as a control node within a decentralized control plane comprising a plurality of control nodes. Separately, Li is relied upon for teaching the claimed decentralized hierarchical control plane comprising a plurality of control nodes arranged in a decentralized hierarchy. As set forth in the rejection, Li teaches a hierarchical distributed control architecture including multiple controllers organized into a decentralized hierarchy, thereby teaching the architectural limitation that Applicant alleges is absent from Muniswamy.
The rejection has not equated Muniswamy’s master controller with the claimed decentralized hierarchical control plane. Instead, the rejection relies on Li for teaching the hierarchical decentralized control plane architecture and on Muniswamy for the operation of a device acting as a control node within such an architecture. As understood to one of ordinary skill in the art, the rejection combines the Li supplied decentralized hierarchical control plan architecture with the Muniswamy supplied control node functionality to teach the applicant argued limitation.
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.
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
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.
Claims 1-3, 7 and 12-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Muniswamy et al. (US 20180091366 A1, published 03/29/2018; hereinafter Muniswamy), in view of Li (US 20150163151 A1, published 06/11/2015; hereinafter Li).
For Claim 1, Muniswamy teaches a method, comprising:
obtaining, at a device (Muniswamy exemplifies the SDN controller 124 being assigned as the new master controller in FIG. 2), an indication that the device is to act as a control node in a decentralized (Muniswamy teaches different SDN controllers for different regions ¶ 0022) … control plane (Muniswamy teaches the assigned new master controller (e.g. 124) receiving the indication for the assigned role of master; FIG. 1, FIG. 2; ¶ 0001 “… A software defined network (SDN) is based on a network architecture that decouples the control plane from the data plane. The control plane is implemented in an SDN controller …”; ¶ 0014 “… FIG. 1 illustrates a block diagram of an example computing environment 100 for selecting a master controller in a software defined network (SDN). The computing environment 100 may include a team of Software Defined Network (SDN) controllers 102 and network devices 104, 106, 108, 110, and 112. In an example, the team of SDN controllers may include three controllers 120, 122, and 124 …”; ¶ 0022 “… A team of three controllers 120, 122, and 124 may be specified for each of the three regions (for example, Region 1, Region 2, and Region 3). For each region, one controller in the team may be specified as master controller. The remaining two controllers may be specified as primary slave controller and secondary slave controller. …”; ¶ 0029 “… FIG. 2 illustrates an example wherein in response to a determination that the value of a parameter for the master controller 120 is above a pre-defined limit (e.g., K> 100), selection engine 156 may select a slave controller from the team as new master controller …”; ¶ 0030 “… In response to the selection of a new master controller in the team, assignment engine may assign the role of master over network devices in the group from the previous master controller 120 to the new master controller (for example, 122) …”), wherein the decentralized … control plane comprises a plurality of control nodes (Muniswamy exemplifies a team of multiple SDN controllers in FIG. 1) …; and …
wherein obtaining the indication that the device (Muniswamy teaches the new master controller 124) is to act as the control node comprises obtaining an indication that a second device (Muniswamy teaches the current master controller 120) acting as a second control node within the decentralized … control plane has become nonoperational or impaired (Muniswamy teaches the slave controller 124 being selected as the new master controller due to detecting the parameter of the current master controller 120 exceeding a predefined limit such as processing resource overload; Examiner notes that the master controller selection process is dynamic, therefore the numbers (e.g. 120, 122, 124) associating with the controllers are used to clearly discuss the process; FIG. 2; ¶ 0029 “… FIG. 2 illustrates an example wherein in response to a determination that the value of a parameter for the master controller 120 is above a pre-defined limit ( e.g., K> 100), selection engine 156 may select a slave controller from the team as new master controller. In this example, the value of the parameter (K=10) for slave controller S2 124 is less than the value of the parameter (K=80) identified for slave controller S1 (122). In this case, slave controller S2 (124) may be selected as new master controller”), …
Muniswamy does not explicitly teach, but Li teaches a decentralized hierarchical control plane and the plurality of control nodes in a decentralized hierarchy (Li exemplifies a hierarchy of distributed controllers of a SDN system in FIG. 1 and FIG. 3; ¶ 0006 “… embodiments of the present disclosure employ a distributed control system to control the network devices in a SDN and thereby manage the network services of a SDN. The distributed control system comprises a hierarchy of controllers including regional controllers and one or more root controllers …”); and
managing, by a processing device at the device (Li teaches processing unit of root controllers or regional controllers in ¶ 0040) acting as the control node and via the decentralized hierarchical control plane, resources associated with a plurality of devices (Li teaches network devices of Control layer and Infrastructure layer in FIG. 3) in the decentralized hierarchy (Li teaches the root controllers or regional controllers managing network topology and resources across domains; FIGS 1-3; ¶ 0017 “… A respective regional controller can be configured to control one or more network devices and maintain a regional network map including the regional network topology, related to the network region that the regional controller manages. A regional controller may have multi-tier and can directly control network devices in the network region, e.g., through virtual routers. A respective root controller can be configured to control a sub-network which includes a group of regional controllers, or the subordinate controller of the root controller, and the associated network devices …”; ¶ 0031 “… a hierarchical control system according to the present disclosure can be used to intelligently and comprehensively control and manages resources of a wide area network (WAN) including multiple subnetworks, e.g., one or more personal area networks (PANs), local area networks (LANs), campus networks (CANs), and metropolitan area networks (MANs) …”; ¶ 0040 “… The infrastructure layer 330 includes the network hardware devices 331-335 coupled in the network, e.g., SDN switches or SDN routers. The control layer 320, or the SDN controller, can offer proprietary programming interfaces to network devices and management. The control layer 320 may include one or more control software programs, e.g., 321-323. One controller program 321, when executed by a processing unit, can perform respective controller function as discussed with reference to FIG. 1 and FIG. 2 …”), …, and
wherein managing the resources comprises managing the resources based on the indication that the second device acting as the second control node within the decentralized hierarchical control plane has become nonoperational or impaired (Li teaches the root controllers or regional controllers (being selected in Muniswamy) managing network topology and resources across domains; FIGS 1-3; ¶ 0017 “… A respective regional controller can be configured to control one or more network devices and maintain a regional network map including the regional network topology, related to the network region that the regional controller manages. A regional controller may have multi-tier and can directly control network devices in the network region, e.g., through virtual routers. A respective root controller can be configured to control a sub-network which includes a group of regional controllers, or the subordinate controller of the root controller, and the associated network devices …”; ¶ 0031 “… a hierarchical control system according to the present disclosure can be used to intelligently and comprehensively control and manages resources of a wide area network (WAN) including multiple subnetworks, e.g., one or more personal area networks (PANs), local area networks (LANs), campus networks (CANs), and metropolitan area networks (MANs) …”).
Muniswamy and Li are analogous art because they are both related to SDN operations.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the decentralized hierarchical control plane techniques of Li with the system of Muniswamy to facilitate augmented scalability and high latency tolerance to an SDN (Li ¶ 0006).
For Claim 2, Muniswamy-Li teaches the method of claim 1, further comprising:
determining, at the device, that the device is to cease acting as the control node (Muniswamy teaches the current master controller 120 determining to select a slave controller as new master controller; Examiner notes that the master controller selection process is dynamic, therefore the numbers (e.g. 120, 122, 124) associating with the controllers are used to clearly discuss the process; FIG. 2; ¶ 0029 “… FIG. 2 illustrates an example wherein in response to a determination that the value of a parameter for the master controller 120 is above a pre-defined limit ( e.g., K> 100), selection engine 156 may select a slave controller from the team as new master controller. In this example, the value of the parameter (K=10) for slave controller S2 124 is less than the value of the parameter (K=80) identified for slave controller S1 (122). In this case, slave controller S2 (124) may be selected as new master controller”);
transmitting, by the device and based on the determination, an indication that a second device (Muniswamy exemplifies controller 124 in FIG. 2) is to act as the control node (Muniswamy, FIG. 2; ¶ 0030 “… In response to the selection of a new master controller in the team, assignment engine may assign the role of master over network devices in the group from the previous master controller 120 to the new master controller (for example, 122 (should be 124 in FIG. 2)) …”); and
ceasing, by the device, managing the resources associated with the plurality of devices subsequent to transmitting the indication that the second device is to act as the control node (Muniswamy teaches transferring the management of network devices to the new master controller; FIG 2; ¶ 0030 “… Referring to the example in FIG. 2, the role of master over network devices (for example, 104, 106, and 108) may be transferred from the previous master controller 120 may be transferred to the new master controller S2 (124). In other words, network devices (for example, 104, 106, and 108) of a region for which the previous controller was the master controller may be transferred to the region of the new master controller. Referring to the example in FIG. 2, network devices of Region 1 may be transferred to Region 3 for which controller 124 may be the master controller …”; Li teaches the controllers managing the resources associated with the network devices). See motivation to combine for claim 1.
For Claim 3, Muniswamy-Li teaches the method of claim 2, further comprising: detecting, at the device, that functionality of the device will be impaired, wherein determining that the device is to cease acting as the control node is based on the detection (Muniswamy teaches the current master controller making controller selection decision based on detecting the parameter exceeding a predefined limit such as processing resource overload; FIG. 1, FIG. 2; ¶ 0027 “… Some non-limiting examples of the parameter that may be monitored by monitoring engine 152 may include: a processing resource usage in a controller, a memory usage in a controller, a disk space usage in a controller, a process on an OpenFlow interface of a controller, and a packet in/out on the OpenFlow interface of a controller …”; ¶ 0029 “… FIG. 2 illustrates an example wherein in response to a determination that the value of a parameter for the master controller 120 is above a pre-defined limit (e.g., K> 100), selection engine 156 may select a slave controller from the team as new master controller. In this example, the value of the parameter (K=10) for slave controller S2 124 is less than the value of the parameter (K=80) identified for slave controller S1 (122). In this case, slave controller S2 (124) may be selected as new master controller”).
For Claim 7, Muniswamy-Li teaches the method of claim 1, further comprising: receiving, at the device (Li teaches a regional controller), an indication of a resource adjustment from a second device acting as a second control node (Li teaches a root controller) in the decentralized hierarchical control plane, wherein the device is associated with a first layer (Li exemplifies the regional controller lower level in FIG. 1) in the decentralized hierarchical control plane and the second device is associated with a second layer (Li exemplifies the root controller upper level in FIG. 1) in the decentralized hierarchical control plane, and wherein the second layer manages the first layer in the decentralized hierarchical control plane (Li teaches the root controller pushes routing information to the regional controller to update the flow table, the flow table updating is associated with network resource adjustment; FIG. 1; ¶ 0019 “… If a lower level controller, e.g., a regional controller, has insufficient route information to determine a route for a packet, an upper level controller, e.g., a root controller, may determine a packet transmission route by using a broader network map contained therein and push relevant route information to the lower level controller. The route information is then used to update the flow table for forwarding the packet …”; ¶ 0024 “… A regional controller can be employed to determine a route by use of the regional network map and modify the default flow table accordingly. Further, if the regional network map still lacks sufficient information to determine the requested route because the destination node is located in another region of the network, a root controller can be employed to determine a requested route by use of the global network map. Subsequently the corresponding regional controller can modify the default flow table based on the route determined by the root controller …”); and
applying, at the device, the resource adjustment based on the indication of the resource adjustment (Li, FIG. 1; ¶ 0024 “… Subsequently the corresponding regional controller can modify the default flow table based on the route determined by the root controller …”). See motivation to combine for claim 1.
For Claim 12, the claim is substantially similar to claim 1 and therefore is rejected for the same reasoning set forth above. Additionally, Muniswamy-Li teaches a system, comprising: a memory; and a processing device, operatively coupled to the memory, to (Muniswamy, FIG. 5; ¶ 0038 “… FIG. 5 is a block diagram of an example system 500 for selecting a master controller in a software defined network (SDN) …”; ¶ 0039 “… The computer readable instructions can also be accessed from memory and executed by a processor …”).
For Claim 13, Muniswamy-Li teaches the system of claim 12, wherein the decentralized hierarchy is associated with at least one of a hybrid cloud environment (Li, ¶ 0031 “… a regional controller along with the associated virtual routers and the network equipments controlled thereby corresponds to a regional network, such as an Information Technology organization, a data center, a cloud, etc. Therefore, a hierarchical control system according to the present disclosure can be used to intelligently and comprehensively control and manages resources of a wide area network (WAN) including multiple subnetworks, e.g., one or more personal area networks (PAN s ), local area networks (LANs), campus networks (CANs), and metropolitan area networks (MANs) …”) or an edge computing environment. See motivation to combine for claim 1.
For Claim 14, Muniswamy-Li teaches the system of claim 12, wherein the resources comprise at least one of: compute resources, network resources (Li, ¶ 0031 “… a hierarchical control system according to the present disclosure can be used to intelligently and comprehensively control and manages resources of a wide area network (WAN) including multiple subnetworks, e.g., one or more personal area networks (PAN s ), local area networks (LANs), campus networks (CANs), and metropolitan area networks (MANs) …”), virtualization associated resources, cloud resources, power resources, or a workload. See motivation to combine for claim 1.
For Claim 15, Muniswamy-Li teaches the system of claim 12, wherein the decentralized hierarchical control plane comprises a plurality of layers (Li exemplifies multiple levels of controllers in FIG. 1 and FIG. 3), and wherein each layer in the plurality of layers is based on at least one of: a geographic region, a device type, a device capability (Li, FIG. 1; ¶ 0022 “… As represented by lines with the label ‘2,’ the root controllers 111 and 112 are also capable of synchronizing the route information with the regional controllers 121-124. For example, the root controller can collect updated network information from the regional controllers and share relevant information from the global network map with the regional controllers …”), or a device use. See motivation to combine for claim 1.
For Claim 16, Muniswamy-Li teaches the system of claim 12, wherein the plurality of devices comprises a first device of a first type (Li teaches SDN switches) and a second device of a second type (Li teaches SDN routers), and wherein the first type is different from the second type (Li, FIG. 3; “… The infrastructure layer 330 includes the network hardware devices 331-335 coupled in the network, e.g., SDN switches or SDN routers …”). See motivation to combine for claim 1.
For Claim 17, the claim is substantially similar to claim 1 and therefore is rejected for the same reasoning set forth above. Additionally, Muniswamy-Li teaches a non-transitory computer-readable medium having instructions stored thereon which, when executed by a processing device of a device, cause the processing device to (Muniswamy, FIG. 5; ¶ 0038 “… System 500 includes a processor 502 and a machine-readable storage medium 504 communicatively coupled through a system bus …”; ¶ 0039 “… The computer readable instructions can also be accessed from memory and executed by a processor …”).
For Claim 18, Muniswamy-Li teaches the non-transitory computer-readable medium of claim 17, wherein to manage the resources associated with the plurality of devices in the decentralized hierarchy, the instructions, when executed by the processing device, cause the processing device (Li teaches a processing unit of a root controller in ¶ 0040) to transmit, to the plurality of devices (Li exemplifies a plurality of regional controllers, SDN routers, SDN switches etc. in FIG. 3), a plurality of indications of adjustments to the resources, wherein the resources are adjusted based on the plurality of indications (Li teaches the root controller pushes routing information to the regional controller(s) to update the flow table(s), the flow table updating is associated with network resource adjustment; FIG. 1; ¶ 0019 “… If a lower level controller, e.g., a regional controller, has insufficient route information to determine a route for a packet, an upper level controller, e.g., a root controller, may determine a packet transmission route by using a broader network map contained therein and push relevant route information to the lower level controller. The route information is then used to update the flow table for forwarding the packet …”; ¶ 0024 “… A regional controller can be employed to determine a route by use of the regional network map and modify the default flow table accordingly. Further, if the regional network map still lacks sufficient information to determine the requested route because the destination node is located in another region of the network, a root controller can be employed to determine a requested route by use of the global network map. Subsequently the corresponding regional controller can modify the default flow table based on the route determined by the root controller …”). See motivation to combine for claim 1.
Claim Rejections - 35 USC § 103
Claim 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Muniswamy et al. (US 20180091366 A1, published 03/29/2018; hereinafter Muniswamy), in view of Li (US 20150163151 A1, published 06/11/2015; hereinafter Li), and in further view of Evans et al. (US 20190036816 A1, published 01/31/2019; hereinafter Evans).
For Claim 4, Muniswamy-Li teaches the method of claim 1 and decentralized hierarchical control plane. Muniswamy-Li does not explicitly teach, but Evans teaches further comprising: monitoring data associated with at least one of the decentralized hierarchy or the decentralized hierarchical control plane (Evans, FIG. 1; ¶ 0025 “… the control device 120 may be configured to manage the control plane of an internal network domain 105 by directing one or more aspects of the operation of the edge network devices 110. The control device 120 may direct data collection activities at various components of the SDN. For example, the control device 120 may direct one or more of the edge network devices 110 to monitor various characteristics of the SDN, such as performance, SLA, security, etc. Monitored data include data associated with the monitored characteristics. The monitored data may include bandwidth data, usage data, carrier data, geography data, user data, application data, site data, loss, latency, jitter, cost data, network events, syslogs, among other data …”; ¶ 0026 “… The devices in the system may send the monitor data securely over a data-bus in real-time to the control device 120 …”),
wherein managing the resources associated with the plurality of devices in the decentralized hierarchy comprises managing the resources based on the data (Evans, FIG. 1; ¶ 0027 “… The control device 120 may generate data models and/or policies based at least in part on the monitor data collected from the various components of the SDN … The control device 120 may generate the data model based on the set of input parameters and the monitor data. For example, the control device 120 may apply machine learning algorithms to the monitored data in order to satisfy use-cases of network planning ( e.g., forecasting), network operations (e.g., SLA policy recommendation, carrier selection), what-if analysis, and network security (anomaly detection) …”).
Evans and Muniswamy-Li are analogous art because they are both related to SDN operations.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the network monitoring and management techniques of Evans with the system of Muniswamy-Li to improve network performance and reliability as well as reduce latency (Evans ¶ 0020).
Claim Rejections - 35 USC § 103
Claim 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Muniswamy et al. (US 20180091366 A1, published 03/29/2018; hereinafter Muniswamy), in view of Li (US 20150163151 A1, published 06/11/2015; hereinafter Li), in view of Evans et al. (US 20190036816 A1, published 01/31/2019; hereinafter Evans), and in further view of Srinivas et al. (US 20150113132 A1, published 04/23/2015; hereinafter Srinivas).
For Claim 5, Muniswamy-Li-Evans teaches the method of claim 4 and decentralized hierarchy. Muniswamy-Li-Evans does not explicitly teach, but Srinivas teaches further comprising: executing, at the device, at least one of a data filtering technique or a data distribution technique on the data (Srinivas, FIG. 9; ¶ 0139 “… The collection process starts (at 901) as a manager obtains API functionality and configuration capabilities from a SDN controller (at 902). The manager computes a sampling schedule as a function of a desired performance objective and topology and sends the sampling schedule to the collector (at 903). The manager also computes and sends instruction for the collector to interact with the SDN controller, other enterprise systems, collect advanced statistics from network elements, and determines how to analyze, filter, and compress from raw data (at 904). The manager also receives raw compressed, filtered features, and other data from the collector (at 905), and indexes and stores the received raw features and data in a database in terms of using time, link and other aspects such as source IP address, as keys (at 906) …”),
wherein managing the resources associated with the plurality of devices in the decentralized hierarchy comprises managing the resources based on executing the at least one of the data filtering technique or the data distribution technique on the data (Srinivas, ¶ 0190 “… Another use case of an automatic closed loop control is where the control objective is to maintain high performance for application X. In this case, the present system and method simply programs rules that place all traffic corresponding to that application into the highest performing queue. If improved application X performance is not observer, the present system and method attempts to program rules that re-routes or rate-limits traffic from applications that share common network links with application X. If improvements are observed, the present system and method restores the performance of other applications. …”).
Srinivas and Muniswamy-Li-Evans are analogous art because they are both related to SDN operations.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the network data filtering techniques of Srinivas with the system of Muniswamy-Li-Evans to improve application performance in the network (Evans ¶ 0190).
Claim Rejections - 35 USC § 103
Claim 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Muniswamy et al. (US 20180091366 A1, published 03/29/2018; hereinafter Muniswamy), in view of Li (US 20150163151 A1, published 06/11/2015; hereinafter Li), in view of Evans et al. (US 20190036816 A1, published 01/31/2019; hereinafter Evans), and in further view of Toy (US 20210351989 A1, published 11/11/2021; hereinafter Toy).
For Claim 6, Muniswamy-Li-Evans teaches the method of claim 4 and decentralized hierarchy. Muniswamy-Li-Evans does not explicitly teach, but Toy teaches further comprising: generating, at the device and via a machine learning model, a prediction pertaining to the resources associated with the plurality of devices based on the data (Toy, FIG. 1; ¶ 0021 “… A network device, a network element, or a network function (referred to herein simply as a network device) may be implemented according to one or multiple network architectures (e.g., a client device, a server device, a peer device, a proxy device, a cloud device, a virtualized function, and/or another type of network architecture (e.g., Software Defined Networking (SDN), virtual, logical, network slicing, etc.)). …”; 0049 “… the AI-based self-capacity management service may calculate future utilization values for network resources, such as network devices 115, virtual network devices 117, and communication links 125 of network 110. According to an exemplary embodiment, the AI-based self-capacity management may use an ML prediction algorithm to estimate future utilization values …”),
wherein managing the resources associated with the plurality of devices in the decentralized hierarchy comprises managing the resources based on the prediction (Toy, FIG. 4; ¶ 0054 “… based on resource and performance data received, orchestrator device 120 may generate predicted values 405, such as future path weights or future performance metric values. Orchestrator device 120 may transmit (e.g., download) the predicted values 410 to network devices 115 and/or virtual network devices 117 of relevance to the network path to which the predicted values pertain. Network devices 115 and virtual network devices 117 may store the predicted values 415 and make routing decisions based on the predicted values 420 …”).
Toy and Muniswamy-Li-Evans are analogous art because they are both related to SDN operations.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the machine learning techniques of Toy with the system of Muniswamy-Li-Evans to reduce operational costs, improve the utilization of resources of the network, application and end devices, as well as improve network performance (Toy ¶ 0018).
Claim Rejections - 35 USC § 103
Claim 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Muniswamy et al. (US 20180091366 A1, published 03/29/2018; hereinafter Muniswamy), in view of Li (US 20150163151 A1, published 06/11/2015; hereinafter Li), and in further view of Manamohan et al. (US 20190332702 A1, published 10/31/2019; hereinafter Manamohan).
For Claim 8, Muniswamy-Li teaches the method of claim 1 and the decentralized hierarchical control plane. Muniswamy-Li does not explicitly teach, but Manamohan teaches further comprising: transmitting, by the device and to at least a subset of the plurality of control nodes in the decentralized hierarchical control plane, a vote pertaining to the resources associated with the plurality of devices (Manamohan teaches a node broadcasting other nodes in the network about the change request proposal, wherein the change request might be associated with network resources as known to one of ordinary skill in the art; FIG. 1, FIG. 4; ¶ 0041 “… In an operation 404, any one or more of the enrolled nodes 10 may propose a change request to the blockchain network. For example, a node 10 may write a blockchain block to the distributed ledger 42 with the change request …”); and
receiving, at the device and from the at least the subset of the plurality of control nodes in the decentralized hierarchical control plane, votes pertaining to the resources associated with the plurality of devices, wherein managing the resources comprises managing the resources based on the vote and the votes (Manamohan teaches a consensus process to make decision on the change request proposal based on received votes; FIG. 1, FIG. 4; ¶ 0042 “… In an operation 406, all enrolled nodes 10 (or at least a minimum number of nodes specified by the smart contracts 44) may participate in a consensus process to determine whether to approve the change request. The consensus process may include a voting process in which at least some of the nodes 10 vote to determine whether to accept the change proposal. In some instances, each node 10 may consult its copy of the smart contracts 44, which may specify voting logic … Each node 10 may generate and transmit a blockchain transaction that specifies its vote to the blockchain network 110 …”; ¶ 0046 “… In an operation 410, each node 10 may implement the change request depending on the outcome of the consensus decision …”).
Manamohan and Muniswamy-Li are analogous art because they are both related to distributed computing network system.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the nodes voting techniques of Manamohan with the system of Muniswamy-Li to securely collaborate the operations of network nodes in a decentralized network system (Manamohan ¶ 0002).
Claim Rejections - 35 USC § 103
Claims 9-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Muniswamy et al. (US 20180091366 A1, published 03/29/2018; hereinafter Muniswamy), in view of Li (US 20150163151 A1, published 06/11/2015; hereinafter Li), and in further view of Khalid (US 20230422077 A1, published 12/28/2023; hereinafter Khalid).
For Claim 9, Muniswamy-Li teaches the method of claim 1 and the decentralized hierarchical control plane. Muniswamy-Li does not explicitly teach, but Khalid teaches wherein the device acts as the control node in a first layer of the decentralized hierarchical control plane (Khalid teaches the level of APs is above the level of end nodes; FIG. 1; ¶ 0016 “… The WLAN controller 110 can communicate with the N routers 122, which may also be configured to communicate with one another to form communication paths through the mesh network 120. Each switch 130 is configured to communicate with at least one router 122 and one or more APs 140, each of which is further configured to handle wireless communications with one or more end nodes 150 …”), the method further comprising:
obtaining, at the device and from a second device (Khalid teaches a WLAN controller in FIG. 1) in the decentralized hierarchical control plane, an indication that the device is to transition from the first layer of the decentralized hierarchical control plane to a second layer of the decentralized hierarchical control plane (Khalid teaches configuring the low-level network device such as an AP to function as a sub-network controller, representing the AP functionally being transitioned to a different level; FIG. 1; ¶ 0020 “… For example, for communications between end node 150a and end node 150b of FIG. 1, AP 140a is the lowest network device that is common to those two end nodes 150a and 150b. If the WLAN controller 110 knows that AP 140a currently has sufficient unused processing and memory resources, then the WLAN controller 110 can program AP 140a to function as an SDN sub-network controller for handling communications between end nodes 150a and 150b without having the corresponding communication signals traverse the WLAN controller 110 (or any switch 130 or router 122) …”); and
transitioning, at the device and based on the indication that the device is to transition, from the first layer of the decentralized hierarchical control plane to the second layer of the decentralized hierarchical control plane (Khalid, FIG. 1; 0020 “… AP 140a receives communication signals from end node 150a and forwards those communication signals to end node 150b without involving any higher-level network devices. Note that, concurrently and/or consecutively, AP 140a can also function as an SDN sub-network controller for handling communications between other pairs of end nodes 150 that have AP 140a in common …”).
Khalid and Muniswamy-Li are analogous art because they are both related to distributed computing network system.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the transitioning the control responsibilities between levels of network devices techniques of Khalid with the system of Muniswamy-Li to improve quality of service (QoS) and reducing latency in hierarchical SDN/VNF-based networks (Khalid ¶ 0001).
For Claim 10, Muniswamy-Li-Khalid teaches the method of claim 9, wherein the indication that the device is to transition is based on at least one of resource availability, network conditions, or system demands (Khalid teaches the transitioning is based on the resource availability; FIG. 1; ¶ 0020 “… If the WLAN controller 110 knows that AP 140a currently has sufficient unused processing and memory resources, then the WLAN controller 110 can program AP 140a to function as an SDN sub-network controller …”). See motivation to combine for claim 9.
Claim Rejections - 35 USC § 103
Claim 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Muniswamy et al. (US 20180091366 A1, published 03/29/2018; hereinafter Muniswamy), in view of Li (US 20150163151 A1, published 06/11/2015; hereinafter Li), and in further view of Gavali et al. (US 20200364086 A1, published 11/19/2020; hereinafter Gavali).
For Claim 19, Muniswamy-Li teaches the non-transitory computer-readable medium of claim 17 and decentralized hierarchy. Muniswamy-Li does not explicitly teach, but Gavali teaches wherein to manage the resources associated with the plurality of devices in the decentralized hierarchy, the instructions, when executed by the processing device, cause the processing device to redistribute a workload from a first subset of the plurality of devices to a second subset of the plurality of devices (Gavali, FIG. 2; ¶ 0036 “… Workload orchestration manager 218 manages workload orchestration environment 226. Workload orchestration environment 226 represents an identifier of the environment, such as, for example, a cloud environment, a data center, or the like, where workload orchestration manager 218 redistributes workloads between worker nodes to optimize performance. Workload orchestration environment 226 includes cluster of worker node groups 228. Cluster of worker node groups 228 comprises a plurality of different groups of worker nodes, such as worker node group 230. Worker node group 230 includes a set of worker nodes …”).
Gavali and Muniswamy-Li are analogous art because they are both related to distributed computing network system.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the transitioning the workload redistribution techniques of Gavali with the system of Muniswamy-Li to facilitate quick application deployment, auto-recovery and self-healing, and seamless application update (Gavali ¶ 0003).
Claim Rejections - 35 USC § 103
Claim 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Muniswamy et al. (US 20180091366 A1, published 03/29/2018; hereinafter Muniswamy), in view of Li (US 20150163151 A1, published 06/11/2015; hereinafter Li), and in further view of Hallur et al. (US 20210034423 A1, published 02/04/2021; hereinafter Hallur).
For Claim 20, Muniswamy-Li teaches the non-transitory computer-readable medium of claim 17 and the decentralized hierarchical control plane. Muniswamy-Li does not explicitly teach, but Hallur teaches wherein the device acting as the control node in the decentralized hierarchical control plane hosts a workload (Hallur teaches that a consumer node which may act as a master node requests services to run a container workload; FIG. 1; ¶ 0019 “… According to various embodiments, a flexible framework is provided that allows for any user or system administrator to opt-in or designate a computing device as a worker node, regardless of the type of network environment in which the computing device resides …”; ¶ 0020 “… a dedicated server and/or cluster of servers can act as a master node that manages an ongoing registry of computing devices that have opted-in to be utilized as worker nodes within the decentralized network computing environment …”; ¶ 0040 “… In embodiments of the invention, container orchestration platform 101 registers consumer nodes in consumer node registry 113. Generally, consumer nodes are computing devices that request services to run a container workload …”; ¶ 0041 “… In some embodiments, a consumer node is a master node residing within a decentralized network computing environment 100 (e.g., a public network computing device 130) requesting services to run a container workload …”).
Hallur and Muniswamy-Li are analogous art because they are both related to distributed computing network system.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the workload orchestration techniques of Hallur with the system of Muniswamy-Li to implement a flexible container orchestration platform within a decentralized network computing environment (Hallur ¶ 0019).
Citation of Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is listed below, thank you:
i. US 20240231873 A1 (Jigalur) teaches providing a high availability control plane in a container-based cluster. The method generally includes determining a first control plane node is unreachable within a cluster; in response to determining the first control plane node is unreachable, activating a second control plane node previously deployed in the cluster, wherein prior to activating the second control plane node the second control plane node comprises: control plane components, not actively running on the second control plane node, that are configured to manage the other components within the cluster; removing the active control plane node from the cluster; determining a number of inactive control plane nodes associated with the second control plane node is less than a minimum number of inactive control plane nodes; and deploying one or more inactive control plane nodes associated with the second control plane node until the minimum number is reached (Abstract).
ii. US 20240330077 A1 (Pasupathilingam) teaches that FIG. 12 illustrates a next level of abstraction provided by Kubernetes, referred to as a "Kubernetes cluster." A Kubernetes cluster comprises a set of highly available, interconnected Kubernetes nodes that are managed by Kubernetes as a computational entity. The nodes in a cluster are partitioned into worker nodes 1202, often simply referred to as "nodes," and master nodes 1204 that together implement a Kubernetes-cluster control plane. In general, only one of the master nodes is active at any given time, with the inactive master nodes providing for immediate failover in the case that the active master node fails. The control plane is responsible for distributing containerized applications among the worker nodes and scheduling execution of the containerized applications (para. [0062]).
Conclusion
THIS ACTION IS MADE FINAL. 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 ZONGHUA DU whose telephone number is (408)918-7596. The examiner can normally be reached Monday - Friday 8 AM - 5 PM PST.
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, John Follansbee can be reached on (571) 272-3964. 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.
/Z.D./Examiner, Art Unit 2444
/SCOTT B CHRISTENSEN/Primary Examiner, Art Unit 2444
Prosecution Insights