Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
2. This action is in response to the amendment filed May 26, 2024.
3. Claims 1, 10, and 19 have been amended.
4. Claims 1-19 have been examined and are pending with this action.
Response to Arguments
5. Applicant's arguments filed May 26, 2024 with respect to the rejection of claims 1, 4, 7, 10, 13, 16, and 19, previously rejected under 35 U.S.C. 102(a) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Allen et al. (US 2012/0057603 A1). Allen has been cited to better teach the amended limitations with respect to the pending independent claims. Please see rejections set forth below.
In response to the argument with respect to Singh not disclosing “selecting a routing path from the plurality of routing paths based on the plurality of saturation metrics”, the applicant(s) is directed to column 4, lines 11-17. Here, Singh describes the gist of the invention wherein load balancing is applied for route selection. “Load balancing may select forwarding paths according to a load balancing scheme (e.g., round robin or hashing), such as scheme-based path selection 114 and scheme-based path selection 134, or according to a path identified programmatically, such as by programmatic path selection 116 and 136.”, emphasis added. It is well-known, routine, and conventional for some sort of metric to be applied that describes/defines a load within a path, such that the load within the plurality of path can be balanced.
Singh further teaches saturation metrics in column 9, lines 34-36, “including forwarding engines that utilize hash values to perform load balancing among different possible forwarding paths.”, and in column 17, lines 3-11, “then a path of load balancing for the stage that is selected according to the load balancing scheme for the stage (e.g., by the hash value, state information indicating the “next” path, or any other data or calculation performed to implement load balancing) may be provided”, emphasis added.
In response to the argument with respect to claims 4 and 13, the applicant asserts that Singh fails to disclose the limitations of claim 4, in particular, “detecting communication status in the routing table”, the examiner disagrees. Singh teaches in column 9, lines 16-39, “For example, internet protocol (IP) headers for the packet may be evaluated with respect to entries in tables, such as a routing or next hop table, to determine forwarding to be performed. Please note that the previous examples of packet forwarding engines 340 is not exhaustive, as many other forwarding decisions may be made, including, but not limited to, forwarding engines for spanning tree protocol (STP) state checking, access port virtual LAN (VLAN) handling, VLAN membership checking, MAC2ME lookup, broadcast/multicast forwarding to a host CPU for the switch (e.g., CPU(s) 230), tunnel start/termination lookup, source MAC lookup, learn filtering, learn requests, moved source MAC checking, multiprotocol label switching (MPLS) label lookups, traffic class mapping, time-to-live (TTL) checks, packet actions based on ingress/egress access control lists (ACL), and/or various other destination resolution lookups. FIGS. 5 and 6 discussed below, provide many examples of different forwarding engines 340, including forwarding engines that utilize hash values to perform load balancing among different possible forwarding paths. As packet forwarding engines 340 make forwarding decisions about the packet (e.g., for L2, L3 and/or tunneling), the decisions are maintained as packet metadata.”, and further teaches in , “If not, as indicated at 730, then a path of load balancing for the stage that is selected according to the load balancing scheme for the stage (e.g., by the hash value, state information indicating the “next” path, or any other data or calculation performed to implement load balancing) may be provided”, emphasis added. Clearly, one of ordinary skill in the art would construe such teaching to be synonymous with the routing table comprising any subjective data, including communication statuses, to make a more informed routing/forwarding decisions.
In response to the argument with respect to dependent claims 7 and 16, the applicant(s) seems to be asserting that Singh fails to disclose the parsing limitation of claim 7 because Singh’s routing table merely stores forwarding information, but not saturation metrics or communication status for nodes. The examiner disagrees.
Regarding routing table storing communication status, please see the response to claim 4 and 13 argument above.
Clearly saturation metrics and communication statuses can be construed as the forwarding information as taught by Singh. Even still, Singh teaches in column 11, lines 52-54, “Programmable field lookup table 462 may be programmed to identify different portions of data within a header for extraction.”, emphasis added.
Singh further teaches in column 14, lines 27-36, “Moreover, allocations of network traffic can be weighted per network traffic flow. Note that weighting may not be based on bandwidth, in some embodiments. Similar to tunnel initiation stage 510, multipath stage 520 may implement multipath group table 522 and pointer table 524. In this way, the group entries (as discussed above with regard to FIG. 6) may be programmed to direct network traffic to valid paths according to the weighting of the network traffic flows assigned to each group entry in pointer table 524 for a group in multipath group table 522.”, emphasis added. Clearly, it is evident from the citations above, routing decisions are by comparing certain header information to whatever routing decision information is necessary to make routing decisions. In the example above, Singh teaches of assigning weights in the tables.
Applicant’s arguments with respect to Baliga have been considered but are moot because the new ground of rejections no longer rely on Baliga.
For at least theses reasons above and the rejections set forth below, Singh clearly and explicitly discloses, teaches, or in the very least, suggests the limitations of the pending dependent claims.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
6. Claims 1- 4, 7, 10-13, 16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. (US 10,887,234 B1) in view of Allen et al. (US 2012/0057603 A1).
INDEPENDENT:
As per claim 1, Singh teaches a computer-implemented method for routing data traffic in a communication network, comprising:
decoding, by a source node in the communication network, an Internet protocol (IP) data packet to determine a destination node (see Singh, col.8, lines 38-45: “Packet parser 320 may parse the packet header to determine and/or extract data for making a forwarding decision for the packet. For example, packet parser 320 may extract different layer headers (e.g., L2, L3, and L4 headers) included in an Internet Protocol (IP) version 4 packet, such as the source MAC address, the destination MAC address, the source IP address, the destination IP address, and port numbers.”);
retrieving, by the source node, a routing table for the destination node, the routing table identifying a plurality of next hop nodes associated with a corresponding plurality of routing paths to the destination node (see Singh, col.4, lines 49-52: “Request 118 may indicate the particular path, in some embodiments, or provide some information for determining or retrieving the identified forwarding path (e.g., lookup table address).”; col.6, lines 47-54: “a controller may be configured to program memory devices with new or additional information (e.g., update next hop tables, action tables, insert or remove forwarding routes, etc.) according to the techniques discussed below with regard to FIGS. 4 and 7 in order to programmatically select load balancing output amongst forwarding paths at different forwarding stages.”; and col.8, lines 53-57: “Packet forwarding engines 340 may access data stored in packet tables 350 to make forwarding and tunneling decisions for the network packet based on information in the packet header (e.g., packet metadata) extracted by packet parser 320.”);
determining, by the source node, a plurality of saturation metrics corresponding to the plurality of routing paths using the routing table, each of the plurality of saturation metrics indicative of data traffic saturation along a corresponding one of the plurality of routing paths, (see Singh, col.5, lines 12-19: “Different numbers of processing stages, possible forwarding paths, load-balancing schemes, and other components (such as stages that do not perform load balancing) may be implemented. Moreover, the organization of components, entries, and other depicted items may be different than those illustrated in FIG. 1 (e.g., load-balancing values/components may be generated in one stage for use at subsequent packet processing stages.)”; col.5, lines 20-24: “This specification begins with a general description of a networking device, which may utilize programmatic selection of load balancing output amongst forwarding paths to evaluate the performance of forwarding network packets at a packet processor along different paths.”; col.5, lines 49-53: “Networking devices may also provide other services when facilitating communications, such as implementing network firewalls, network intrusion detection, and/or collecting metrics for performance analysis.”; col.8, lines 45-52: “The extracted data may then be utilized to perform lookups to make forwarding decisions at packet forwarding engines 340. Packet parser 320 may also be used to generate hash values for performing load balancing amongst different paths at subsequent stages in ingress pipeline 302, as discussed in detail below with regard to FIG. 4, including enabling or disabling programmatic selection of paths as the output of load balancing for different stages.”; col.9, lines 30-40: “including forwarding engines that utilize hash values to perform load balancing among different possible forwarding paths. As packet forwarding engines 340 make forwarding decisions about the packet (e.g., for L2, L3 and/or tunneling), the decisions are maintained as packet metadata. The packet metadata may be provided to scheduler 360 for scheduling determinations.”; and col.11, lines 55-61: “In at least some embodiments, packet parser 320 may implement hash engine(s) 470 to generate hash values 406 based on extracted metadata 404. Such hash values may be utilized to perform hash-based load balancing across different possible forwarding paths for a network packet at different forwarding stages, such as discussed below with regard to FIGS. 5 and 6.”);
selecting a routing path from the plurality of routing paths based on the plurality of saturation metrics (see Singh, column 4, lines 11-17, “Load balancing may select forwarding paths according to a load balancing scheme (e.g., round robin or hashing), such as scheme-based path selection 114 and scheme-based path selection 134, or according to a path identified programmatically, such as by programmatic path selection 116 and 136.”; col.9, lines 34-36: “including forwarding engines that utilize hash values to perform load balancing among different possible forwarding paths.”; col.17, lines 3-11: “then a path of load balancing for the stage that is selected according to the load balancing scheme for the stage (e.g., by the hash value, state information indicating the “next” path, or any other data or calculation performed to implement load balancing) may be provided”; and col.19, lines 19-24: “and wherein the packet processor selects from among the plurality of possible forwarding paths according to the load balancing scheme when the packet processor is configured to not provide the programmatically identified path as the selected path of the load balancing”); and
forwarding the IP data packet to a next hop node in the selected routing path (see Singh, col.19, lines 25-26: “and forwarding, by the packet processor, the network packet according to the selected programmatically identified path.”).
Singh does not explicitly teach that each of the plurality of saturation metrics being based at least in part on a ratio of data traffic load to a maximum peak load supported by at least one node along the corresponding one of the plurality of routing path.
Allen teaches each of the plurality of saturation metrics being based at least in part on a ratio of data traffic load to a maximum peak load supported by at least one node along the corresponding one of the plurality of routing path (see Allen, Figs. 1, 2, & 4; [0023]: “Hence, a first intermediate router 120 has access to a maximum of 1 Gbps when transmitting data on a third routing path 114, but only to a maximum of 500 Mbps when using one of its ports to transmit data via a fourth routing path 115. These static metric values are subsequently used to determine which routing paths to use to route data from the source node 110 to the destination node 111. FIG. 1 shows the maximum bandwidth available at each data routing path 112-119.”; and [0046]: “A link utilization value can be determined based on this utilization to weight the corresponding link appropriately. By increasing the data stored by the forwarding database, additional bandwidth profiling information per service is available for use in load distribution calculations. In another embodiment, only the minimum link metrics of the set of links in a path is utilized as representative of the maximum load that could be offered between that pair of nodes. In other embodiments, similar metrics or more detailed metrics can be utilized.”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the system of Singh in view of Allen so that the plurality of saturation metrics being based at least in part on a ratio of data traffic load to a maximum peak load supported by at least one node along the corresponding one of the plurality of routing path. One would be motivated to do so because network utilization is commonly defined as load divided by capacity and further because Singh teaches in column 5, lines 9-19, “Please note that the previous description of programmatic selection of load balancing output amongst forwarding paths is not intended to be limiting but is provided as a logical example. Different numbers of processing stages, possible forwarding paths, load-balancing schemes, and other components (such as stages that do not perform load balancing) may be implemented. Moreover, the organization of components, entries, and other depicted items may be different than those illustrated in FIG. 1 (e.g., load-balancing values/components may be generated in one stage for use at subsequent packet processing stages.)”), emphasis added.
As per claim 10, Singh and Allen teach a source node for routing data traffic in a communication network, the source node comprising:
a non-transitory memory storing instructions (see Singh, col.6, line 59-col.7, line 10: “A non-transitory computer-readable storage medium may include any mechanism for storing information in a form (e.g., software, processing application) readable by a machine (e.g., a computer)... ”); and
at least one processor in communication with the memory, the at least one processor configured, upon execution of the instructions, to perform the following steps (see Singh, col.17, lines 11-19: “A programmatically identified path may be provided to a packet processor by a controller, or other component, via an interface, control/status register, or other form of programmatic instruction that indicates the path to output for load balancing (or the information used to generate or discover the selected path, such as a hash value which may then be used to identify a path linked to the hash value).”):
decoding an Internet protocol (IP) data packet to determine a destination node;
retrieving a routing table for the destination node, the routing table identifying a plurality of next hop nodes associated with a corresponding plurality of routing paths to the destination node (see Claim 1 rejection above);
determining a plurality of saturation metrics corresponding to the plurality of routing paths using the routing table, each of the plurality of saturation metrics indicative of data traffic saturation along a corresponding one of the plurality of routing paths, and each of the plurality of saturation metrics being based at least in part on a ratio of data traffic load to a maximum peak load supported by at least one node along the corresponding one of the plurality of routing paths (see Claim 1 rejection above);
selecting a routing path from the plurality of routing paths based on the plurality of saturation metrics (see Claim 1 rejection above); and
forwarding the IP data packet to a next hop node in the selected routing path (see Claim 1 rejection above).
As per claim 19, Singh and Allen teach a non-transitory computer-readable medium storing computer instructions for routing data traffic in a communication network, that configure at least one processor, upon execution of the instructions, to perform the following steps (see Claim 10 rejection above):
decoding an Internet protocol (IP) data packet to determine a destination node (see Claim 1 rejection above);
retrieving a routing table for the destination node, the routing table identifying a plurality of next hop nodes associated with a corresponding plurality of routing paths to the destination node (see Claim 1 rejection above);
determining a plurality of saturation metrics corresponding to the plurality of routing paths using the routing table, each of the plurality of saturation metrics indicative of data traffic saturation along a corresponding one of the plurality of routing paths, and each of the plurality of saturation metrics being based at least in part on a ratio of data traffic load to a maximum peak load supported by at least one node along the corresponding one of the plurality of routing paths (see Claim 1 rejection above);
selecting a routing path from the plurality of routing paths based on the plurality of saturation metrics (see Claim 1 rejection above); and
forwarding the IP data packet to a next hop node in the selected routing path (see Claim 1 rejection above).
DEPENDENT:
As per claims 2 and 11, which respectively depend on claims 1 and 10, although Singh selecting of the routing path (see Singh, col.4, lines 49-57: “Request 118 may indicate the particular path, in some embodiments, or provide some information for determining or retrieving the identified forwarding path (e.g., lookup table address). Once programmatic path selection 116 is enabled, the identified path may be continually be provided as load balancing 112 output for processing each received network packet 100 until a different path is identified for programmatic path selection or programmatic path selection is disabled.”), Singh does not explicitly teach selecting a highest saturation metric from the plurality of saturation metrics, the highest saturation metric corresponding to the routing path; and detecting the highest saturation metric is higher than a threshold saturation metric.
Allen teaches selecting a highest saturation metric from the plurality of saturation metrics, the highest saturation metric corresponding to the routing path (see Allen, [0026]: “In subsequent passes through the database to generate further ECT sets, the set of shortest paths between any two points is first ranked by generating path utilization values that can include the lexicographically sorted link utilization values for each of the paths or simply the sum of the utilization of each link in the path and then ranking the resulting paths based on the path utilization values. Two or more ranking schemes can be also utilized, because when selecting more than one path when generating an ECT set it is advantageous to minimize the number of times the same path is selected…. When more than one ranking (e.g., a lowest ranking and a highest ranking) is considered, then the lowest utilized path is selected as both the lowest and highest ranking path. When there is more than one equally lowest utilized path, the common algorithm tie-breaking process is applied to the set of lowest utilized paths to make the selection.”); and detecting the highest saturation metric is higher than a threshold saturation metric (see Allen, [0046]: “In another embodiment, only the minimum link metrics of the set of links in a path is utilized as representative of the maximum load that could be offered between that pair of nodes. In other embodiments, similar metrics or more detailed metrics can be utilized.”; and [0066]: “Where a uniquely lowest loaded path exists it can be selected without further processing for all path rankings (e.g lowest and highest).”)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the system of Singh in view of Allen by implementing selecting a highest saturation metric from the plurality of saturation metrics, the highest saturation metric corresponding to the routing path; and detecting the highest saturation metric is higher than a threshold saturation metric.
One would be motivated to do so because Singh teaches in column 4, lines 8-17, “Different possible forwarding paths, such as possible forwarding paths 120 and 140, may be selected for network packets 100. Load balancing, such as load balancing 112 and 132, may be implemented to distribute network packets amongst the different possible forwarding paths. Load balancing may select forwarding paths according to a load balancing scheme (e.g., round robin or hashing), such as scheme-based path selection 114 and scheme-based path selection 134, or according to a path identified programmatically, such as by programmatic path selection 116 and 136.”.
As per claims 3 and 12, which respectively depend on claims 2 and 11, Singh teaches further comprising: selecting a second routing path from the plurality of routing paths, the second routing path has a second highest saturation metric from the plurality of saturation metrics; and switching routing the IP data packet from the selected routing path to the second routing path (see Singh, col.3, lines 54-58: “multiple instances of load balancing may occur across different paths in a packet processing pipeline, dramatically increasing the possible number of paths a network pack can travel and increasing the difficulty of evaluating one or multiple ones of a large number of possible paths.”; col.4, lines 8-17: “Different possible forwarding paths, such as possible forwarding paths 120 and 140, may be selected for network packets 100. Load balancing, such as load balancing 112 and 132, may be implemented to distribute network packets amongst the different possible forwarding paths. Load balancing may select forwarding paths according to a load balancing scheme (e.g., round robin or hashing), such as scheme-based path selection 114 and scheme-based path selection 134, or according to a path identified programmatically, such as by programmatic path selection 116 and 136.”; and col.18, claim 1, “to change output of load balancing performed among a plurality of possible forwarding paths, wherein the load balancing is currently configured to select from among the plurality of possible forwarding paths according to a load balancing scheme, wherein the request indicates the load balancing configuration is to be changed to output a programmatically identified path of the plurality of possible forwarding paths,”).
As per claims 4 and 13, which respectively depend on claims 1 and 10, Singh teaches further comprising: parsing the routing table to further determine a saturation metric and communication status for at least a first set of nodes forming the selected routing path and a second set of nodes forming a second routing path of the plurality of routing paths; detecting network congestion for the selected routing path is above a threshold congestion level; detecting the communication status in the routing table for a node of the second set of nodes indicates the node is turned off; and encoding a configuration message for transmission to a management node of the communication network based on detecting the network congestion and the communication status, the configuration message requesting the management node to turn on the node of the second set of nodes (see Singh, col.8, lines 47-57: “Packet parser 320 may also be used to generate hash values for performing load balancing amongst different paths at subsequent stages in ingress pipeline 302, as discussed in detail below with regard to FIG. 4, including enabling or disabling programmatic selection of paths as the output of load balancing for different stages. Packet forwarding engines 340 may access data stored in packet tables 350 to make forwarding and tunneling decisions for the network packet based on information in the packet header (e.g., packet metadata) extracted by packet parser 320.”; and column 9, lines 16-39, “For example, internet protocol (IP) headers for the packet may be evaluated with respect to entries in tables, such as a routing or next hop table, to determine forwarding to be performed. Please note that the previous examples of packet forwarding engines 340 is not exhaustive, as many other forwarding decisions may be made, including, but not limited to, forwarding engines for spanning tree protocol (STP) state checking, access port virtual LAN (VLAN) handling, VLAN membership checking, MAC2ME lookup, broadcast/multicast forwarding to a host CPU for the switch (e.g., CPU(s) 230), tunnel start/termination lookup, source MAC lookup, learn filtering, learn requests, moved source MAC checking, multiprotocol label switching (MPLS) label lookups, traffic class mapping, time-to-live (TTL) checks, packet actions based on ingress/egress access control lists (ACL), and/or various other destination resolution lookups. FIGS. 5 and 6 discussed below, provide many examples of different forwarding engines 340, including forwarding engines that utilize hash values to perform load balancing among different possible forwarding paths. As packet forwarding engines 340 make forwarding decisions about the packet (e.g., for L2, L3 and/or tunneling), the decisions are maintained as packet metadata.”, and further teaches in column 17, lines 3-8, “If not, as indicated at 730, then a path of load balancing for the stage that is selected according to the load balancing scheme for the stage (e.g., by the hash value, state information indicating the “next” path, or any other data or calculation performed to implement load balancing) may be provided”).
As per claims 7 and 16, which respectively depend on claims 1 and 10, Singh teaches further comprising: parsing the routing table to determine a saturation metric and communication status for a plurality of nodes forming the plurality of routing paths (see Singh, col.8, lines 57-65: “packet forwarding engines 340 may perform lookups for data in layer 2 (L2) portions of the packet to perform L2 forwarding. L2 forwarding may access a MAC address table in packet tables 350 perform two lookups (which may be in parallel). The first lookup may be performed with a key extracted from the packet header at packet parser 320 (e.g., a VLAN and source MAC address), to determine whether an entry for the packet is present in the MAC address table”; and Claim 4 rejection above).
7. Claims 8-9 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Singh et al. (US 10,887,234 B1) and Allen et al. (US 2012/0057603 A1), and still further in view of Baliga et al. (US 2012/0320924 A1).
As per claims 8 and 17, which respectively depend on claims 7 and 16, neither Singh nor Allen teach further comprising: decoding a notification message broadcast by at least one node of the plurality of nodes, the at least one node associated with a second routing path of the plurality of routing paths, and the notification message indicating the saturation metric for a communication interface of the at least one node is below a threshold saturation metric.
Baliga teaches decoding a notification message broadcast by at least one node of the plurality of nodes, the at least one node associated with a second routing path of the plurality of routing paths, and the notification message indicating the saturation metric for a communication interface of the at least one node is below a threshold saturation metric (see Baliga, [0023]: “The automatic network path modification system can determine the minimum number of packet streams associated with the current source interface that should to be shifted to alternate network interfaces of the hybrid communication device so that the medium utilization of the current source interface falls below the medium utilization threshold”; and [0025]: “The hybrid communication devices can identify and migrate one or more packet streams to alternate network interfaces (as will be described below in FIGS. 1-7C) only if the communication medium is still oversubscribed after their respective back-off time interval elapses”).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the invention to modify the system of Singh and Allen in view of Baliga by implementing decoding a notification message broadcast by at least one node of the plurality of nodes, the at least one node associated with a second routing path of the plurality of routing paths, and the notification message indicating the saturation metric for a communication interface of the at least one node is below a threshold saturation metric.
One would be motivated to do so because Singh teaches in column 4, lines 8-17, “Different possible forwarding paths, such as possible forwarding paths 120 and 140, may be selected for network packets 100. Load balancing, such as load balancing 112 and 132, may be implemented to distribute network packets amongst the different possible forwarding paths. Load balancing may select forwarding paths according to a load balancing scheme”, and further teaches in column 13, line 67-column 14, line 3, “However, when programmatic selection is not enabled, then hash values 640 may change from one network packet to the next, balancing the utilization of different elements, and thus different pointers and possible paths.”.
As per claims 9 and 18, which respectively depend on claims 8 and 17, Singh teaches further comprising: excluding the second routing path from the plurality of routing paths during the selecting of the routing path, based on the notification message (see Singh, [0058]: “In some implementations, the communication medium can be considered to be oversubscribed if the medium utilization of the communication medium exceeds the total capacity of the communication medium. In other implementations, the communication medium can be considered to be oversubscribed if the medium utilization of the communication medium exceeds the medium utilization threshold associated with the communication medium. By iteratively constructing the medium utilization analysis graph 730 as described above in blocks 312-324, the number of packets streams to be analyzed can be minimized, a minimum number of packet streams that should be migrated from the current source interface can be identified in a minimum number of iterations, and solutions that do not meet performance criteria (e.g., packet streams that cannot be migrated, potential source interfaces that cannot support migration of the selected packet streams, etc.) can be discarded. After the next packet stream to be analyzed is selected”; and [0071]: “The minimum performance thresholds may be user-defined (e.g., the minimum data rate at which a packet can be transmitted, a minimum throughput, etc.), application-specific (e.g., based on requirements/specifications of the destination application), and/or determined by the destination device (e.g., the minimum data rate that can be supported by the destination device). Throttling the packet streams can refer to reducing the performance (e.g., throughput) associated with the packet stream to the predetermined minimum performance threshold (e.g., the minimum acceptable throughput).”).
Claim Objections
8. Claims 5-6 and 14-15 are 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:
The prior art of record does not disclose, teach, or suggest neither singly nor in combination the claimed limitation of “detecting available communication interfaces of the source node have been idle for a threshold duration; and encoding a configuration message for transmission to a management node of the communication network, the configuration message requesting the management node to turn off the source node” as recited in dependent claims 5 and 14.
Claims 6 and 15, are allowable because they respectively depend on the allowable features of claims 5 and 14.
Conclusion
9. For the reasons above, claims 1-4, 7-13, and 16-19 have been rejected, claims 5-6 and 14-15 have been objected to, and claims 1-19 remain pending.
10. 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.
11. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL Y WON whose telephone number is (571)272-3993. The examiner can normally be reached on Wk.1: M-F: 8-5 PST & Wk.2: M-Th: 8-7 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, Nicholas R Taylor can be reached on 571-272-3889. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Michael Won/Primary Examiner, Art Unit 2443
Prosecution Insights