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 .
Response to Arguments
Applicant’s arguments, see pages 2-3, filed on October 29, 2025, with respect to the rejection(s) of claim(s) 1 and 10 under U.S.C. 103 as being unpatentable over Koppol et al. (US 20050278779 A1 –hereinafter-- Koppol”) in view of Mehtaet al. (US 20180287905 A1 –hereinafter- “Mehta”) 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 Aggarwal et al. (US 8571029 B1 –hereinafter- “Aggarwal”).
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.
Claims 1, 3-4, 10 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over Koppol et al. (US 20050278779 A1 –hereinafter-- Koppol”) in view of Aggarwal et al. (US 8571029 B1 –hereinafter- “Aggarwal”).
As per claim 1:
Koppol discloses a method comprising:
receiving traffic information for a first autonomous system ([0019] As used herein, a "flow" is generally defined as a stream (unidirectional or bi-directional) of packets traveling between two points in a network that all have the same characteristics. Nevertheless, a flow may include only a single packet sent from one point to another point in a network. A flow is identified by reading select information (called "flow identifiers") from a header of one or more packets. In one implementation, the select information is read from the source Internet Protocol (IP) address, the destination IP address, the IP port, and/or the IP protocol-type portions of a header. In other implementations, it is possible that other select information may be read from packets. [0029] Network 100 includes several autonomous systems 102(1), 102(2), 102(3), . . . , 102(N). Each AS may include one or more networks (not shown), such as local area networks (LANs) and/or wide area networks (WANs). Each autonomous system (AS), referred to generally as reference number 102, may be coupled together in a variety of different ways via computing devices such as gateways, routers, servers, bridges, etc. For example, each AS 102 includes one or more ingress routers, which serve as access points for packets to enter an AS (ingress routers may also be referred to as entry edge routers). In the illustrious embodiment, ingress routers 104(1), 104(2), 104(3), . . . 104(N) are shown in AS 102(1), 102(2), 102(3), . . . 102(N), respectively, although it is appreciated that are generally several ingress routers per AS. The term AS may also be referred to as a domain herein. [0030] To collect flow information at various points in network 100 flow tables 106(1), 106(2), 106(3), . . . , 106(N) are maintained at each ingress router 104. These flow tables, referred to generally as reference number 106, are databases containing flow information collected from its respective ingress router 104. That is, each flow table 106 contains flow information about packets entering an AS 102. Each flow table 106 may be maintained by its respective ingress router 104 or may be maintained by other computer devices able to communicate with ingress routers 104. Additionally, if there is more than one ingress router, it is possible to aggregate information collected from each ingress router into a single flow table);
wherein the traffic information includes:
router identifier information identifying at least one ingress router receiving traffic at the first autonomous system ([0020] As used herein, "flow information" refers to statistical information associated with flows collected at various points in a network, such as at the ingress and/or egress ports of autonomous systems. By analyzing flow information, it is possible to ascertain where a stream of packets originated or terminated. In other words, when a DoS attack is recognized, the flow information is retrieved from the different points and analyzed to reconstruct a path taken by at least one packet associated with the DoS attack. The analysis may involve querying each ingress port of an autonomous system starting with the autonomous system in which the victim node resides and tracing backwards from the victim's autonomous system to neighboring autonomous systems until the source(s) of a DoS attack (or at least the autonomous system(s) from which the attack is being launched) can be identified. It is also possible that the methodologies described herein can be used within an autonomous system, i.e., intra autonomous system attack-source identification. [0032] A flow is identified by reading select information (called "flow identifiers") from a header of one or more packets received by each ingress router 104 of an AS 102. That is, for each incoming packet p, at a time t(p) a flow identifier i(p) is recorded. For instance, FIG. 2 shows flow identifiers 202 derived from a header 200 of an IP packet, which are used to identify flows. In one implementation, the select information is read from the source IP address 204, the destination IP address 206, the IP port 208, and the IP protocol-type portions (i.e., protocol) 210 of a header 200. The flow identifiers 202 enable flows to be uniquely identified); and
identification of a source of the traffic ([0033] Depending on the type of packets being sent, different flow identifiers may be used to determine flows. For instance with Internet Control Message Protocol (ICMP) it is only necessary to record the first type field. For other types of packets, other information may be recorded, such as the source, and destination port from the IP payload. In addition, a 1-byte protocol field in the IP packet can be used to further distinguish the flow. It is noted that ICMP packets do not have any port information. [0034] Accordingly, to identify flows, only flow identifiers from the packet header, need be recorded, although it is possible that other select information may be read from packets);
determining whether the router identifier information matches expected router information for the source of the traffic ([0032] A flow is identified by reading select information (called "flow identifiers") from a header of one or more packets received by each ingress router 104 of an AS 102. That is, for each incoming packet p, at a time t(p) a flow identifier i(p) is recorded. For instance, FIG. 2 shows flow identifiers 202 derived from a header 200 of an IP packet, which are used to identify flows. In one implementation, the select information is read from the source IP address 204, the destination IP address 206, the IP port 208, and the IP protocol-type portions (i.e., protocol) 210 of a header 200. The flow identifiers 202 enable flows to be uniquely identified. [0066] In block 602, flow information observed at various points in a network are collected and recorded. The flow information recorded at each location in the network provides a profile of network traffic observed at the collection points. For example, flow information is collected at various ingress routers 104 (FIG. 1) of various autonomous systems 102 (FIG. 1). Flow table modules 508 operating in association with ingress routers 104 records select header information (flow identifiers 202 (FIG. 2)) associated with flows to build a statistical log about flows in flow tables 106 maintained in the various autonomous systems 102. This flow information can be analyzed to trace back the source of a DoS attack.); and
causing, based at least in part on determining that the router identifier information does not match the expected router information for the source of the traffic, a threat mitigation action to be invoked ([0039-0040] Each AS 102 also includes at least one traceback server 108(1), 108(2), 108(3), . . . , 108(N). Each traceback server is primarily configured to retrieve flow information from flow tables 106, communicate with other traceback servers, and communicate with victims of a DoS attack. [0067] In block 604, a victim detects a DoS attack. For instance, a victim 110 may recognize a large quantity of (potentially invalid) service requests that are disproportionate to previous levels of similar service requests for a particular period of time. Such a large quantity of service requests may indicate may indicate that a DoS attack is being perpetrated. There are many other ways to detect whether a DoS attack is being perpetrated. For instance, a victim 110 (FIG. 1) may detect that there is unusual quantity of protocol errors associated with requests or a large quantity of fragments associated with requests. Again, all these scenarios are indicative of a DoS attack and for purposes of this discussion, most DoS attack detection methods schemes used to detect such anomalies may be used in conjunction with method 600. Such detection methodologies may be incorporated as a module used conjunction with traceback system 500 (FIG. 5).
wherein determining whether the router identifier information matches the expected ingress router information further comprises:
extracting the router identifier information from a plurality of sampled packets received by the first autonomous system (Koppol [0032] A flow is identified by reading select information (called "flow identifiers") from a header of one or more packets received by each ingress router 104 of an AS 102. That is, for each incoming packet p, at a time t(p) a flow identifier i(p) is recorded. For instance, FIG. 2 shows flow identifiers 202 derived from a header 200 of an IP packet, which are used to identify flows. In one implementation, the select information is read from the source IP address 204, the destination IP address 206, the IP port 208, and the IP protocol-type portions (i.e., protocol) 210 of a header 200. The flow identifiers 202 enable flows to be uniquely identified);
determining, from the router identifier information, ingress routers for the traffic during a period of time (Koppol [0035-0036] FIG. 3 shows an exemplary flow table 106 maintained at each ingress router 104. As indicated above, ingress routers 104 generally maintain flow tables 106, which serve as searchable databases. Flow table 106 generally includes a flow identifier column 302 and timestamp column 304. Typically, each flow identifier associated with a flow is recorded in flow identifier column 302. A timestamp associated with each flow (the most recent time the flow was seen) is typically recorded in timestamp column 304 in tandem with the flow identifiers recorded in column 302. By using a timestamp in conjunction with each flow, it is possible to search for particular flows during a certain period of time. [0059] In one implementation, flow table module 508 is configured to enable ingress routers 102 to collect flow information observed at various points in the network, such as ingress routers 104. Flow table module 508 records select header information (flow identifiers 202) associated with flows to build a statistical log about flows in flow tables 106. [0039] Each AS 102 also includes at least one traceback server 108(1), 108(2), 108(3), . . . , 108(N). Each traceback server is primarily configured to retrieve flow information from flow tables 106, communicate with other traceback servers, and communicate with victims of a DoS attack. Koppol [0040] Suppose a traceback server 108(1) receives notification of a DoS attack from a victim 110. Traceback server 108(1) will first query flow table 106(1) belonging to AS 102(1) searching for flow information pertinent to the DoS attack on victim 110. Once the flow information is retrieved, it is analyzed by the traceback server 108(1). If the flow information indicates that the attack packets originated from a neighboring AS, such as AS 102(2), traceback server 108(1) will communicate with a neighboring traceback server 108(2), and request that traceback server 108(2) query flow table 106(2) for information pertinent to the DoS attack. When traceback server 108(2) obtains the pertinent flow information it will forward the information directly back to traceback server 108(1). Traceback server 108(1) will then process the flow information to determine the next set of ASs to be queried. And the process will repeat propagating further away from the victim's 110 AS 102(1) to neighboring AS's 102(3), . . . , 102(N). This process will continue until it is possible for the traceback server 108(1) to aggregate the flow information and trace the DoS attack back to a set of/particular AS from which a DoS emanates. Now, it is possible to take action to eliminate the attack from the source(s), such as through filtering or other action as seen fit by the victim 10 or the AS that hosts the attack source(s));and
determining ingress routers during the period of time based on historical data (Koppol [0035-0036] FIG. 3 shows an exemplary flow table 106 maintained at each ingress router 104. As indicated above, ingress routers 104 generally maintain flow tables 106, which serve as searchable databases. Flow table 106 generally includes a flow identifier column 302 and timestamp column 304. Typically, each flow identifier associated with a flow is recorded in flow identifier column 302. A timestamp associated with each flow (the most recent time the flow was seen) is typically recorded in timestamp column 304 in tandem with the flow identifiers recorded in column 302. By using a timestamp in conjunction with each flow, it is possible to search for particular flows during a certain period of time. [0059] In one implementation, flow table module 508 is configured to enable ingress routers 102 to collect flow information observed at various points in the network, such as ingress routers 104. Flow table module 508 records select header information (flow identifiers 202) associated with flows to build a statistical log about flows in flow tables 106. [0066] In block 602, flow information observed at various points in a network are collected and recorded. The flow information recorded at each location in the network provides a profile of network traffic observed at the collection points. For example, flow information is collected at various ingress routers 104 (FIG. 1) of various autonomous systems 102 (FIG. 1). Flow table modules 508 operating in association with ingress routers 104 records select header information (flow identifiers 202 (FIG. 2)) associated with flows to build a statistical log about flows in flow tables 106 maintained in the various autonomous systems 102. This flow information can be analyzed to trace back the source of a DoS attack).
Koppol does not explicitly disclose the determined ingress routers include distribution of the ingress routers and an expected distribution of the ingress routers. Aggarwal, in analogous art however, discloses the determined ingress routers include distribution of the ingress routers (Column 6: lines 15-50: Inter-area P2MP segmented LSP 15 is established between root node PE router 12A and leaf nodes PE routers 12B-12E by establishing intra-area LSPs within each of routing areas 22 to carry intra-area segments of inter-area P2MP segmented LSP 15 and stitching the intra-area segments together to establish inter-area P2MP segmented LSP 15. More specifically, the intra-area LSPs are established within each of routing areas 22 by advertising a BGP Leaf auto-discovery route for an intra-area segment of inter-area P2MP segmented LSP 15 within each of routing areas 22, and establishing the intra-area LSPs within each of routing areas 22 based on the BGP Leaf auto-discovery route for the intra-area segment using a multicast Multi-Protocol Label Switching (MPLS) protocol. The multicast MPLS protocol used to establish the intra-area LSPs within each of routing areas 22 may include the multicast label distribution protocol (mLDP) and the resource reservation protocol with traffic engineering (RSVP-TE). ABRs 14 act as route reflectors for BGP auto-discovery routes. Once the intra-area LSPs are established within each of routing areas 22, PE router 12A and ABRs 14 may perform binding of the intra-area LSPs to inter-area P2MP segmented LSP 15 within each of routing areas 22. More specifically, PE router 12A and ABRs 14 may advertise the binding using BGP Provider Multicast Service Interface (PMSI) auto-discovery routes for inter-area P2MP segmented LSP 15 that each includes an identity of the intra-area LSP and an upstream-assigned MPLS label of the intra-area segment within the routing area. In the case where the intra-area LSP is used solely for inter-area P2MP segmented LSP 15, the MPLS label in the BGP PMSI auto-discovery route is set to null. In examples where the service carried by inter-area P2MP segmented LSP 15 is IP multicast, the intra-area LSPs within egress routing areas 22C and 22D may not be bound to inter-area P2MP segmented LSP 15, and one or more leaf nodes PE routers 12B-12E of inter-area P2MP segmented LSP 15 may forward multicast traffic using IP multicast forwarding information stored in leaf nodes 12B-12E).
Aggarwal, further includes in (column 8: lines 8-20: Allow the AS to use BGP as the inter-area label distribution protocol, and allow each of the routing areas within the AS to independently use one of the multicast MPLS protocols, e.g., mLDP or RSVP-TE, as its intra-area label distribution protocol. Since the scope of a given intra-area label distribution protocol is generally limited to a single routing area, neighboring routing areas may use different intra-area label distribution protocols. The techniques are also applicable to inter-area P2MP segmented LSPs carrying multicast services, including multicast VPLS instances, MVPN instances, and IP multicast instances. Moreover, the techniques described herein for seamless MPLS multicast may be used with seamless MPLS unicast) and an expected distribution of the ingress routers (in column 24; lines 36-54: If the intra-area LSP is used to carry two or more intra-area segments of different inter-area P2MP segmented LSPs, control unit 282 needs to be configured to determine whether a given multicast packet for a particular (S, G) is received from an expected upstream ingress PE router or ingress ABR. The expected router is the router to which auto-discovery unit 310 of egress ABR 280 sent the BGP Leaf auto-discovery route. Control unit 282 will drop any multicast packets received from an unexpected router for that (S, G). To allow the leaf nodes of the inter-area P2MP segmented LSP to determine the sender, the intra-area LSP in the egress area must be signaled with no penultimate hop popping (PHP). In the case where signaling unit 312 uses mLDP 300 as the intra-area label distribution protocol in the egress routing area, and the RD of the received BGP Leaf auto-discovery route is zero, which is the case when the service is IP multicast, then auto-discovery unit 310 of egress ABR 280 may originate a BGP S-PMSI auto-discovery route within the egress routing area).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the plurality of packets disclosed by Koppol to include the determined ingress routers include distribution of the ingress routers and an expected distribution of the ingress routers. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide techniques for multicast communication in a seamless Multi-Protocol Label Switching (MPLS) architecture with improved scalability including thousands of provider edge (PE) routers within different routing areas of the same Autonomous System (AS) that require point-to-multipoint (P2MP) connectivity to receive multicast communication for associated customer networks and building of inter-area P2MP segmented label switched paths (LSPs) within an AS by stitching together intra-area segments of the inter-area P2MP segments LSPs as suggested by Aggarwal (column 2: lines 15-25).
As per claim 3:
Koppol in view of Aggarwal discloses the method of claim 1, wherein the identification of the source of the traffic is a source IP address in each of the sampled packets (Koppol [0032] A flow is identified by reading select information (called "flow identifiers") from a header of one or more packets received by each ingress router 104 of an AS 102. That is, for each incoming packet p, at a time t(p) a flow identifier i(p) is recorded. For instance, FIG. 2 shows flow identifiers 202 derived from a header 200 of an IP packet, which are used to identify flows. In one implementation, the select information is read from the source IP address 204, the destination IP address 206, the IP port 208, and the IP protocol-type portions (i.e., protocol) 210 of a header 200. The flow identifiers 202 enable flows to be uniquely identified).
As per claim 4:
Koppol in view of Aggarwal discloses the method of claim 1, where the identification of the source of the traffic is an autonomous-system identifier for a second autonomous system (Koppol [0032] A flow is identified by reading select information (called "flow identifiers") from a header of one or more packets received by each ingress router 104 of an AS 102. That is, for each incoming packet p, at a time t(p) a flow identifier i(p) is recorded. For instance, FIG. 2 shows flow identifiers 202 derived from a header 200 of an IP packet, which are used to identify flows. In one implementation, the select information is read from the source IP address 204, the destination IP address 206, the IP port 208, and the IP protocol-type portions (i.e., protocol) 210 of a header 200. The flow identifiers 202 enable flows to be uniquely identified).
As per claims 10 and 12-13:
Claims 10 and12-13 are directed to a system comprising: at least one processor; and memory, operatively connected to the at least one processor and storing instructions that, when executed by the at least one processor, cause the system to perform corresponding limitation of a method claims 1 and 3-4 respectively and therefore, claims 10 and 12-13 are rejected with the same rationale given above to reject claims 1 and 3-4 respectively.
Claims 5-9 and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Koppol et al. (US 20050278779 A1 –hereinafter-- Koppol”) in view of Aggarwal et al. (US 8571029 B1 –hereinafter- “Aggarwal”) in further view of Kommareddy et al. (US 20080028467 A1 –hereinafter-- “Kommareddy”).
As per claim 5:
Koppol in view of Aggarwal discloses determines whether the router identifier information matches the expected ingress router information. Koppol in view of Mehta discloses does not explicitly disclose incrementing a threat measure when the router identifier information for any packet of the plurality of packets does not match the expected distribution of ingress routers; and determining whether the threat measure exceeds a threshold. Kommareddy, in analogous art however, discloses incrementing a threat measure when the router identifier information for any packet of the plurality of packets does not match the expected distribution of ingress routers ([0015] A stub domain comprises an autonomous system (AS), i.e., a collection of IP networks and routers under the control of a single entity that presents a common routing policy to the Internet. For example, in the well-known border gateway protocol (BGP), each stub domain, or AS, has assigned thereto a unique AS number, or ASN, for use in BGP routing. The ASN thus uniquely identifies the stub domain on the Internet ([0016] Several DoS detection and prevention mechanism. [0087] Monitors are deployed at routers 902-916 and the network contains other routers, collectively illustrated at 920, that are not monitored. An asymmetric flow's outgoing packets traverse the routers on path 932 and exit the autonomous system at router 916. Incoming packets enter the AS at router 902 and traverse the routers on path 934. Thus, monitors in the AS will only sample outgoing or incoming packets of the asymmetric flows. [0129] A score is computed over time for each of the counters to detect counters to which attack flows are mapped. Scores are computed using the net increments of counters over the period. The detection threshold is set proportional to the sampling rate. The score may be bounded between 0 and the detection threshold to minimize the effect of an old state on the detection process); and
determining whether the threat measure exceeds a threshold ([0096] If a flow is masked, that is, has a flow rate less than the score threshold, the detection system of the present invention will not classify the flow as an attack, thereby reducing the incidences of false positive reports. The penalty paid for this approach is that attacks with less than the score threshold will not be reported and increase the false negative rate. [0097] A monitor's score threshold may be proportional to the average number of flows in its bin and the average flow rate of its flows. In certain embodiments, for simplicity, the invention may use a single value for the score threshold for all flows and monitors. In such an event, the score threshold used will be the maximum of the score thresholds at individual monitors. [0129] A score is computed over time for each of the counters to detect counters to which attack flows are mapped. Scores are computed using the net increments of counters over the period. In certain embodiments of the invention, the detection threshold is set proportional to the sampling rate. The score may be bounded between 0 and the detection threshold to minimize the effect of an old state on the detection process).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the plurality of packets disclosed by Koppol in view of Aggarwal discloses to include incrementing a threat measure when the router identifier information for any packet of the plurality of packets does not match the expected distribution of ingress routers; and determining whether the threat measure exceeds a threshold. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a scalable DoS detection system that is deployable at a stub domain and that is robust against attacks directed to individual hosts as well as entire subnets as suggested by Kommareddy ([0024]).
As per claim 6:
Koppol and Aggarwal in view of Kommareddy disclose the method of claim 1, wherein determining whether the router identifier information matches the expected ingress router information further comprises:
determining whether the distribution of ingress routers for the traffic during the period of time differs from the expected distribution of ingress routers during the period of time by at least a threshold amount (Kommareddy [0135] The detection scheme on subnet attacks previously described is deployable in networks in which all legitimate flows are assumed symmetric. If the network has legitimate asymmetric flows, such as in the multi-gateway systems previously described, those flows may also be flagged as attacks. For example, consider a network having 2 gateways G1 and G2, where a first flow 00 is a symmetric flow, another flow 01 is an attack flow and a third flow 10 is an asymmetric flow, as shown in FIG. 19A. The asymmetric flow's outgoing packets exit the network at gateway G1 and the incoming packets enter at gateway G2. The result of deploying the single gateway subnet detection scheme in this network is shown in FIG. 19B. In the Figure, the left digit of the flow identifier is mapped to the row of the counters shown and the right digit of the flow identifier is mapped to the column of the counters. As expected, the single gateway detection system would flag flow 01 as an attack flow. However, as seen in the Figure it will also flag flow 10 as an attack, even though that flow is legitimate).
As per claim 7:
Koppol and Aggarwal in view of Kommareddy disclose the method of claim 1, further comprising:
causing the router identifier information for the at least one ingress router to be changed periodically to new router identifier information (Kommareddy [0139] using the asymmetric tables, the monitors collectively identify legitimate asymmetric flows and detect attacks. In the following descriptions as to how the tables are updated, the updates are described using only symmetric and asymmetric IP-indexed tables, or simply symmetric and asymmetric tables. Any update to the entries of an IP-indexed table will result in a similar update to entries in the corresponding hash-indexed table. The only difference would be what entries are update); and
updating a router mapping table with the new router identifier information (Kommareddy [0141] The per-packet updates to the symmetric tables are identical to the per-packet updates to the tables in the single gateway embodiment. Recall from a previous discussion, that the entries in the tables corresponding to an asymmetric flow have net increments. In the single gateway network, the asymmetric flows at the gateway are attacks. In the multi-gateway network, asymmetric flows at a gateway may be attacks or legitimate. Thus, due to the update mechanism described above, only entries of the symmetric table that correspond to either attacks or outgoing components of legitimate asymmetric flows will have net increments. If symmetric tables at all monitors are combined, then the entries of this aggregate symmetric table will identify all asymmetric flows in the network. The periodic processing function at the monitor uses this aggregated symmetric table to update its asymmetric table, which in turn distinguishes between legitimate asymmetric flows and attack flows).
As per claim 8:
Koppol and Aggarwal in view of Kommareddy disclose the method of claim 7, wherein the new router identifier information includes an expiration time, wherein the expected ingress router information is determined from the router mapping table, and the router identifier information includes a timestamp indicating when the at least one ingress router received the traffic at the first autonomous system (Kommareddy [0142] The aspects of periodic processing for the multi-homed case proceeds as follows. The symbols S.sub.m(t) and A.sub.m(t) will represent respectively the symmetric and asymmetric tables at a monitor m at the end of interval t. At the beginning of interval t+1, the periodic processing component of monitor m computes increment table .DELTA.S.sub.m(t) as follows: .DELTA.S.sub.m(t)=S.sub.m(t)-S.sub.m(t-1), where monitor m reports its increment table to a designated monitor referred to as the rendezvous node).
As per claim 9:
Koppol and Aggarwal in view of Kommareddy disclose the method of claim 7, wherein the router identifier information comprises a router identifier that is different from either an Internet protocol (IP) address or media access control address (Kommareddy [0015] border gateway protocol (BGP), each stub domain, or AS, has assigned thereto a unique AS number, or ASN, for use in BGP routing. The ASN thus uniquely identifies the stub domain on the Internet).
As per claims 15-18:
Claims 15-18 are directed to a system comprising: at least one processor; and memory, operatively connected to the at least one processor and storing instructions that, when executed by the at least one processor, cause the system to perform corresponding limitation of a method claims 5 and 7-9 respectively and therefore, claims 15-18 are rejected with the same rationale given above to reject claims 5 and 7-9 respectively.
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure. See the notice of reference cited in form PTO-892 for additional prior arts.
Esale US 20150244615 discuses a Label Distribution Protocol (LDP) extensions that enable distribution of neighbor-label mappings for directly connected neighbor routers. A router capable of supporting the LDP extensions distributes neighbor-labels to be used by the router to label switch traffic destined for the directly connected neighbor router irrespective of a hop-by-hop Interior Gateway Protocol (IGP) path determined based on link metrics. The neighbor-labels may increase backup coverage, e.g., link protection and/or node protection, in a network that, due to link metrics, does not have a viable loop-free alternate (LFA) path between an ingress router and an egress router of a label switched path (LSP). In addition, the neighbor-labels may improve load balancing by enabling an ingress router in a first autonomous system (AS) to select a particular remote link on which to send traffic destined for remote routers in a second AS.
Klinker et al US 20060182034 describes uses proxy points for measuring different routes to a destination address space. Multiple paths to the desired destination address space are identified. Each path begins at a source and terminates at the destination address space. Proxy points are identified for each path and are associated with a point between the source and the destination address space. Measurements of the path performance from each source to the appropriate proxy point are compared to determine an optimum route.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
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, LINGLAN EDWARDS can be reached on (571) 270-5440. 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.
/TECHANE GERGISO/Primary Examiner, Art Unit 2408