DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Response to Amendment
Regarding the objection of claim 20 for reciting Internet version 4 (IPv6), instead of Internet version 6 (IPv6). Appropriate correction has been made to the claim; therefore, the claim objection is withdrawn.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a receiving module configured to”, “ a first analysis module configured to”, “ a second analysis module configured to”, “a message generation module configured to”, “an encapsulation module configured to”, “ a sending module configured to”, in claim 8.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Response to Arguments
Regarding examiner’s claim interpretation under 35 U.S.C. 112(f), applicant did not provide any remark or response to examiner remarks; therefore, examiner’s claim interpretation is maintained.
Applicant’s arguments with respect to claim(s) 1 and 9 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claim(s) 1-5, 8-14 and 17-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Monier et al. (US 2020/0007425 A1), in view of Ahearn et al. (US 5,926,463).
Regarding claim 1, Monier discloses a method for detecting (traceroute) a public network forwarding device (intermediate device/tunnel entrance device 104) applied to a public network forwarding device (Monier [0014], discloses a traceroute method for identifying an intermediate device in a tunneled segment of a routing path) and comprising:
receiving a TRACE message (traceroute/probe request received by an intermediate public forwarding device) performed by outer layer (outer tunnel header) encapsulation based on a preset protocol (ICMPv6) (Monier, fig.4, [0051] at 402, a traceroute application executing on the probe source device 102 may send a first probe request to the probe destination device 114 with a hop limit value of one (HL=1). The tunnel entrance device 104 may receive the first probe, decrement the hop limit value to zero (HL=0), and then send an ICMPv6 Hop Limit Exceeded in transit error message back to the prove source device 102), and
analyzing a Hop Limit (HL) value from the outer layer encapsulation of the TRACE message (Monier, fig.4, [0051] the tunnel entrance device 104 may receive the first probe, decrement the hop limit value to zero (HL=0), and then send an ICMPv6 Hop Limit Exceeded in transit error message back to the prove source device 102),
wherein the preset protocol (ICMPv6, TCP) is a transmission protocol that is supported by a public network where a public network forwarding device (routers, switches, security gateways) is located (Monier, figs. 5 & 8, [0018;0052; 0059], discloses detailed traceroute communications on a routing tunnel of an IP network implementing protocols such as TCP, ICMPv6, ICMPv4, or other protocols are supported by routers, switches, security gateways and other devices corresponding to locations in the internet. The protocols may be preset/preconfigured the forwarding devices (routers, switches, security gateways and other devices) and used for data transmission between devices in the network),
analyzing the TRACE message (traceroute/probe request) when the HL value indicates that the last hop has been reached (Monier [0012] a probe request sent to probe a destination device may have an associated hop limit value and may be increased by 1 for each successive probe towards the destination. In this way, each downstream device disposed on the routing path between the probe source device and the probe destination device may receive a probe with a hop limit value of one and, after decrementing the hop limit value to zero, generate an error message for the traceroute program to use in its diagnostics. This process may then repeat until an error in the routing path has been determined and/or the probe destination device is reached, as indicated by the probe source device executing the traceroute application receiving an ICMPv6 Port Unreachable error packet and/or another type of message indicating that the probe destination device was reached), and
acquiring a source Internet Protocol (IP) (ICMPVv4/IPv4 or ICMPVv6/IPv6) carried in the TRACE message (Monier [0012;0042;0059] traceroute packets sent from the probe source device are sent using a preset protocol, ICMPVv6/IPv6. Each intermediate device and the destination device decapsulates the traceroute/probe packet sent by the source device to acquire the specific protocol carried in the packet or with which the probe packet was sent (ICMPVv4/IPv4 or ICMPVv6/IPv6). Once an Internet protocol is acquired from a source traceroute or probe request, the protocol is used for communication between the forwarding devices (routers, switches, security gateways and other devices corresponding to locations in the internet) in the tunnel as detailed in figs. 4&5)
generating a response message (error message), setting a destination IP (Tunnel entrance device) in the response message as the source IP in the TRACE message (Monier [0051] The error message may contain the source address of the tunnel entrance device 104, i.e., the IP address of the tunnel entrance device 104 (S=TS)), and
setting a source IP in the response message as an IP of the public network forwarding device (Monier [0052] at 404, after receiving the error message sent by the tunnel entrance device 104 at the probe source device 102, the probe source device may send a response in the form of a second probe request to the probe destination device 114 with a hop limit value of 2 (HL=2). The second probe (response) generated by the probe source device will carry the IP address of the probe source device as the address of the second probe/response); and
performing outer layer encapsulation on the response message based on the preset protocol (ICMPv6) (Monier [0051-0052; 0061], at 404, after receiving the error message, the traceroute application executing at the probe source device 102 may send a second probe request to the probe destination device 114 with a hop limit value of 2 (HL=2). The tunnel entrance device 104 may receive the second probe, decrement the hop limit value by one (HL=1), and then encapsulate the second probe using a preset protocol ICMPv6 within an IP tunnel header. In fig. 4, the hop limit value of the tunnel header supersedes the hop limit value of the second probe request (HL=X/Y where X is the outer tunnel header hop limit, in this case 64, and Y is the inner header (tunneled) hop limit, in this case 1). The tunneled probe request is then forwarded downstream by the tunnel entrance device 104 to tunneled intermediate device 110(1). I ),
respectively setting the source IP and the destination IP in the outer layer encapsulation of the response message as the source IP and a destination IP in the outer layer encapsulation of the TRACE message (Monier [0042;0051-0052], each message that is communicated through the tunnel contains a source and destination IP address. In fig. 4, the hop limit value of the tunnel header supersedes the hop limit value of the second probe request (HL=X/Y where X is the outer tunnel header hop limit, in this case 64, and Y is the inner header (tunneled) hop limit, in this case 1). Based on the source and destination IP addresses contained in each packet/message, the tunneled probe request is then forwarded downstream by the tunnel entrance device 104 to tunneled intermediate device 110(1). Intermediate device 110(1) may receive the tunneled probe message, decrement the outer tunnel header hop limit value by 1 (HL=63/1), and then forward the tunneled probe request message downstream to intermediate device 110(2). Intermediate device 110(2) may receive the tunneled probe request, decrement the outer tunnel header hop limit value by 1 (HL=62/1), and then forward the tunneled probe request downstream to the tunnel exit device 112(1)) and
sending the response message performed by the outer layer encapsulation (Monier [0012; 0042;0051-0052], In fig. 4, the hop limit value of the tunnel header supersedes the hop limit value of the second probe request (HL=X/Y where X is the outer tunnel header hop limit, in this case 64, and Y is the inner header (tunneled) hop limit, in this case 1). Based on the source and destination IP addresses contained in each packet/message, the tunneled probe request is then forwarded downstream by the tunnel entrance device 104 to tunneled intermediate device 110(1). Intermediate device 110(1) may receive the tunneled probe message, decrement the outer tunnel header hop limit value by 1 (HL=63/1), and then forward the tunneled probe request message downstream to intermediate device 110(2). Intermediate device 110(2) may receive the tunneled probe request, decrement the outer tunnel header hop limit value by 1 (HL=62/1), and then forward the tunneled probe request downstream to the tunnel exit device 112(1)).
While Monier discloses sending the response message performed by the outer layer encapsulation [0012; 0042;0051-0052], Ahearn more explicitly disclose sending the response message performed by the outer layer encapsulation in a hop-by-hop manner.
Ahearn discloses Ahearn more explicitly disclose sending the response message performed by the outer layer encapsulation in a hop-by-hop manner (Ahearn, Col. 13, line 60 – col. 14, line 11, discloses assessing problems in the distribution of IP multicast traffic can be difficult. Mtrace utilizes a tracing feature implemented in multicast routers (mrouted version 3.3 and later) that is accessed via an extension to the IGMP protocol. A trace query is passed hop-by-hop along the reverse path from the receiver to the source, collecting hop addresses, packet counts, and routing error conditions along the path, and then the response is returned to the requestor).
One of ordinary skill would have been motivated to combine the teachings of Monier, and Ahearn because these teachings are from the same field of endeavor with respect to tracing a route in a tunnel and monitoring the status of devices along a path using traceroute or probe application.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Ahearn into the method by Monier, thereby providing the capability of viewing a configuration of a computer network by polling a plurality of switches and routers present in the network to obtain copies of information stored in databases on the switches and routers. The system determines from this combined database is the status of the links, switches and routers, as well as uses software tools to determine the status of the network and its devices. The devices are then graphically displayed according to physical connectivity and status. Each status being displayed differently, Ahearn, [Abstract].
Regarding claim 2, Monier modified by Ahearn disclose the method according to claim 1, wherein after analyzing the HL value from the outer layer encapsulation of the TRACE message, the method further comprises:
re-performing outer layer encapsulation on the TRACE message based on the preset protocol when the HL value indicates that the last hop is not reached, and subtracting 1 from the HL value in the outer layer encapsulation during re-performing of the outer layer encapsulation; and sending the TRACE message re-performed by outer layer encapsulation (Monier [0052] at 404, after receiving the error message, the traceroute application executing at the probe source device 102 may send a second probe request to the probe destination device 114 with a hop limit value of 2 (HL=2). The tunnel entrance device 104 may receive the second probe, decrement the hop limit value by one (HL=1), and then encapsulate the second probe within an IP tunnel header).
The motivation to combine is similar to that of claim 1.
Regarding claim 3, Monier modified by Ahearn disclose the method according to claim 1, wherein analyzing the TRACE message if the HL value indicates that the last hop has been reached (Monier [0012] when an intermediate tunnel device receives a probe request for a tunnel destination device from a tunnel source device, the intermediate device analyzes the hop limit value of the request and decrements it by one (1). If the hop limit value in the probe reaches zero at an intermediate device after it has been decremented, the intermediate device sends an error message to the probe source indicating that the hop limit has been depleted before the probe gets to the intended probe destination. Upon receipt of the error message, the probe source device, the source device generates and sends a new probe request to the probe destination device with an increased hop limit value. The hop limit value may be increased by 1 for each successive probe. In this way, each downstream device disposed on the routing path between the probe source device and the probe destination device may receive a probe with a hop limit value of one and, after decrementing the hop limit value to zero, generate an error message for the traceroute program to use in its diagnostics. This process may then repeat until an error in the routing path has been determined and/or the probe destination device is reached, as indicated by the probe source device executing the traceroute application receiving an ICMPv6 Port Unreachable error packet and/or another type of message indicating that the probe destination device was reached) and
acquiring the source IP (address of the probe source device) carried in the TRACE message (Probe or request packet) (Monier [0051-0052] each message communicated through the tunnel contains a source and a destination IP address. When the tunnel entrance device 104 may receive the first probe, decrement the hop limit value to zero (HL=0), and then send an ICMPv6 Hop Limit Exceeded in transit error message back to the probe source device 102. The error message may be de-capsulated to extract the source IP address contained in the error message. Based on the source IP address that is acquired from the probe request, an ICMPv6 Hop Limit Exceeded in transit error message back to the prove source device 102. The error message may contain the source address of the tunnel entrance device 104, i.e., the IP address of the tunnel entrance device 104 (S=TS))) comprises:
analyzing the TRACE message (traceroute/probe/request packet) when the HL value (HL value = zero (0)) indicates that the last hop has been reached (destination device) (Monier [0012] when a traceroute/probe/request containing a hop limit is transmitted from a source device, the hop limit value may be increased by 1 for each successive probe. In this way, each downstream device disposed on the routing path between the probe source device and the probe destination device may receive a probe with a hop limit value of one and, after decrementing the hop limit value to zero, generate an error message for the traceroute program to use in its diagnostics. This process may then repeat until an error in the routing path has been determined and/or the probe destination device is reached, as indicated by the probe source device executing the traceroute application) and
the public network forwarding device (intermediate device/Tunnel entrance or exit device/edge router) is configured to support a mode of analyzing (decapsulation of the request header to acquire IP address of a source device) an inner layer message, and acquiring the source IP carried in the TRACE message (error message) (Monier [0020; 0051-0052] discloses a daemon operating on the tunnel entrance device (public network forwarding device) may listen or analyze the header of response messages by decapsulating the packet, for ICMPv6 Hop Limit Exceeded error messages from one or more tunneled intermediate devices. In response to receiving such an error message, the daemon may generate a new ICMPv6 Hop Limit Exceeded error message containing the original probe request packet and an IP address corresponding to the specific tunneled intermediate device that generated the original error message. In fig. 4, the hop limit value of the tunnel header supersedes the hop limit value of the second probe request (HL=X/Y where X is the outer tunnel header hop limit, in this case 64, and Y is the inner header (tunneled) hop limit, in this case 1). The tunneled probe request is then forwarded downstream by the tunnel entrance device 104 to tunneled intermediate device 110(1). This process is repeated until the probe reaches an intended final destination).
The motivation to combine is similar to that of claim 1.
Regarding claim 4, Monier modified by Ahearn disclose the method according to claim 1, wherein
receiving the TRACE message (traceroute/request packet) performed by outer layer encapsulation based on the preset protocol (ICMPv6) comprises (Monier [0056;0059] at step 412, a probe source device 102 may send a probe to a destination device 114 with a hop limit value. The tunnel entrance device 104 receives the probe and encapsulates the probe within an IP tunnel header. The traceroute/probe packet may be encapsulated using a preset protocol such as TCP protocol, ICMPv6 protocol, ICMPv4 protocol, as well as other communication protocols):
receiving, from a first side adjacent network device (Figs. 4&5 – 104, 110 (1)) the TRACE message (traceroute/probe) performed by outer layer encapsulation (encapsulation of a traceroute/probe packet) based on the preset protocol (ICMPv6) (Monier, figs. 4, [0055], at 410, the tunneled probe request is then forwarded by the tunnel entrance device 104 to tunneled intermediate device 110(1). Tunneled intermediate device 110(1) receives the tunneled probe request, decrements the outer tunnel header hop limit value by 1 (HL=0/1), and then sends a hop limit exceeded error message containing the source address of tunneled intermediate device 110(1) back to the tunnel entrance device 104),
wherein the first side adjacent network device is another public network forwarding device or a first Provider Edge (PE) (Monier, figs. 4&5, [0034-0035; 0052], discloses network communication devices beginning from a probe source device “S” 102, a tunnel entrance device 104 and a plurality of tunneled intermediate device(s) 110(1), 110(2), . . . 110(M) (collectively referred to as “tunneled intermediate devices 110”), where M is any integer greater than or equal to 1. Each tunnel intermediate device (110-1, 110-M) is a public adjacent network device forwarding packets between the probe source device “S” and the probe destination device “D” 114. Packets received by any one of the public forwarding devices are forwarded either upstream or downstream through an adjacent forwarding device towards the intended destination); and
sending the response message (response to an error message) performed by the outer layer encapsulation comprises (Monier [0061-0064], at 506, a second traceroute/probe may be sent by the source probe device 102 in response to receiving the error message from the tunnel entrance device 104. All communication including the responses packets transmitted in the tunnel include an encapsulation of an outer header using a preset protocol such as TCP protocol, ICMPv6 protocol, ICMPv4 protocol, as well as other communication protocols):
sending the response message performed by the outer layer encapsulation to a second side adjacent network device (Monier, figs. 4&5, [0034-0035; 0052; 0061-0064], each tunnel intermediate device (110-1, 110-M) is a public adjacent network device forwarding packets between the probe source device “S” and the probe destination device “D” 114. Packets received by any one of the public forwarding devices are forwarded either upstream or downstream through an adjacent forwarding device towards the intended destination. At 506, a second traceroute/probe may be sent by the source probe device 102 in response to receiving the error message from the tunnel entrance device 104. All communication including the responses packets transmitted in the tunnel include an encapsulation of an outer header using a preset protocol such as TCP protocol, ICMPv6 protocol, ICMPv4 protocol, as well as other communication protocols);
wherein the second side adjacent network device is still another public network forwarding device or a second PE (Monier, figs. 4&5, [0034-0035; 0052; 0061-0064], each tunnel intermediate device (110-1, 110-M) is a public adjacent network device forwarding packets between the probe source device “S” and the probe destination device “D” 114).
The motivation to combine is similar to that of claim 1.
Regarding claim 5, Monier modified by Ahearn disclose the method according to claim 4, wherein after sending the response message performed by the outer layer encapsulation to the second side adjacent network device, the method further comprises device (Monier, figs. 4&5, [0034-0035; 0052; 0061-0064], disclose tunnel intermediate devices (110-1, 110-M) that are public adjacent network devices used to for forwarding encapsulated packets between the probe source device “S” and the probe destination device “D” 114):
forwarding the response message to the first side adjacent network device when the second side adjacent network device receives the response message performed by the outer layer encapsulation again based on the preset protocol (Monier, figs. 4&5, [0034-0035; 0052; 0061-0064], each tunnel intermediate device (110-1, 110-M) is a public adjacent network device forwarding packets between the probe source device “S” and the probe destination device “D” 114. Packets received by any one of the public forwarding devices are forwarded either upstream or downstream through an adjacent forwarding device towards the intended destination. At 506, a second traceroute/probe may be sent by the source probe device 102 in response to receiving the error message from the tunnel entrance device 104. All communication including the responses packets transmitted in the tunnel include an encapsulation of an outer header using a preset protocol such as TCP protocol, ICMPv6 protocol, ICMPv4 protocol, as well as other communication protocols. In fig. 4, the hop limit value of the tunnel header supersedes the hop limit value of the second probe request (HL=X/Y where X is the outer tunnel header hop limit, in this case 64, and Y is the inner header (tunneled) hop limit, in this case 1). The tunneled probe request is then forwarded downstream by the tunnel entrance device 104 to tunneled intermediate device 110(1). This process is repeated until the probe reaches an intended final destination).
The motivation to combine is similar to that of claim 1.
Regarding claim(s) 8, the claim(s) is/are rejected with rational similar to that of claim(s) 1.
Regarding claim 9, Monier discloses a public network forwarding device (Fig. 2, tunnel entrance and/or exit device 200), comprising: at least one processor (206), and a memory (208), communicatively connected to the at least one processor, wherein the memory stores an instruction executable by the at least one processor, and when the instruction is executed by the at least one processor, the at least one processor is configured to (Monier, fig. 2, [0039] a tunnel entrance and/or exit device 200 may include a processing unit 202 and one or more network interfaces 204. The processing unit 202 may include one or more processors 206 and memory 208. The one or more processors 206 may comprise microprocessors, central processing units, graphics processing units, or other processors usable to execute program instructions to implement the functionality):
The rest of the limitations of claim 9 are rejected with rational similar to that of claim 1.
Regarding claim 10, Monier modified by Ahearn disclose a non-transitory computer-readable storage medium, storing a computer program, wherein the computer program is configured to, when executed by a processor, perform the method as claimed in claim 1 fig. 2, [0039] a tunnel entrance and/or exit device 200 may include a processing unit 202 and one or more network interfaces 204. The processing unit 202 may include one or more processors 206 and memory 208. The one or more processors 206 may comprise microprocessors, central processing units, graphics processing units, or other processors usable to execute program instructions to implement the functionality).
The motivation to combine is similar to that of claim 9.
Regarding claim(s) 11-14, the claim(s) is/are rejected with rational similar to that of claim(s) 2-5, respectively.
Regarding claim 17, Monier modified by Ahearn disclose the method according to claim 1, wherein the response message is an Internet Control Message Protocol (ICMP) error response message (Monier [0064] At 510, the tunneled intermediate device 110(1) may receive the tunneled probe request message described in block 508, decrement the hop limit value of the IP tunnel header of the probe to zero, and generate an ICMPv6 Hop Limit Exceeded error message).
The motivation to combine is similar to that of claim 9.
Regarding claim 18, Monier modified by Ahearn disclose the method according to claim 1, wherein the HL represents the number of remaining nodes that the message needs to pass through (Monier [0012] a probe request sent by a probe source device contains a hop limit value, referred to as a time to live (TTL) value in IPv4. Downstream devices between source and destination nodes of a probe request may generate an error message indicating that the minimum hop limit value required to reach the probe destination device exceeds the hop limit value of the probe request. That is, when the hop limit value in the probe reaches zero, the intermediate, device that decremented the hop limit value to zero may send the error message to the probe source indicating that the hop limit has been depleted. That is, the hop limit value in the probe request should reflex the number of nodes the probe need to pass through to the probe destination).
The motivation to combine is similar to that of claim 9.
Regarding claim 19, Monier modified by Ahearn disclose the method according to claim 3, wherein the public network forwarding device is provided with a mode configuration switch, and when the configuration switch is on, the public network forwarding device is configured to support the mode of analyzing the inner layer message (Monier [0018; 0078] the probe source device, the tunnel entrance device, the intermediate tunneled device, tunnel exit device and the probe destination device may be relays, meters, routers, switches, transformers, security gateways, combinations of any of these or other computing devices with routing capability. That is, these devices are capable of being configured to route communications from one device to another. At blocks 538, 540, and 542, a fifth probe request may be routed through the IP network to the tunnel exit device 112(1) (switch). The tunnel exit device/switch may be configured so that when the tunneled probe message of block 542 is sent to the tunnel exit device/switch 112(1), analyses the hop limit value of the outer IP header to be equal to two ([2]), while the hop limit value of the inner probe message may be equal to ([4])).
The motivation to combine is similar to that of claim 9.
Regarding claim 20, Monier modified by Ahearn disclose the method according to claim 1, wherein the TRACE message is an Internet Protocol version 4 (IPv4) TRACE message or an Internet Protocol version 6 (IPv6) TRACE message (Monier [0012;0017;0041; 0046] each downstream device disposed on the routing path between the probe source device and the probe destination device may receive a probe with a hop limit value of one and, after decrementing the hop limit value to zero, generate an error message for the traceroute program to use in its diagnostics. This process may then repeat until an error in the routing path has been determined and/or the probe destination device is reached, as indicated by the probe source device executing the traceroute application receiving an ICMPv6 Port Unreachable error packet and/or another type of message indicating that the probe destination device was reached. Protocols for sending messages are not limited to the IPv6 protocol and may be applicable to other protocols and corresponding error messages as well. As one non-limiting example, the techniques may include sending/receiving ICMPv4 Port Unreachable error packets in the context of the IPv4 protocol).
The motivation to combine is similar to that of claim 9.
Claim(s) 6-7 and 15-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Monier et al. (US 2020/0007425 A1), in view of Ahearn et al. (US 5,926,463), further in view of Shi et al. (US 2021/0218704 A1).
Regarding claim 6, Monier modified by Ahearn disclose the method according to claim 1, but did not explicitly disclose wherein the source IP carried in the TRACE message is an IP of the PE or an IP of a Customer Edge (CE).
Shi discloses wherein the source IP carried in the TRACE message is an IP of the PE or an IP of a Customer Edge (CE) (Shi, figs. 1&2, [0074], segment routing over IPv6 or a SRv6 network includes plurality of network devices that either physical or virtual routers or switches. The devices may be referred to as a customer edge (CE) device, a provider edge (PE) device, or a provider (P) device, based on a deployment location. A datagram protocol (UDP) detection packet 1 is encapsulated in an IP packet header. A destination IP address of the IP header that encapsulates the UDP detection packet 1is an IP address of PE2 of figs. 1&2).
One of ordinary skill would have been motivated to combine the teachings of Monier, Ahearn and Shi because these teachings are from the same field of endeavor with respect to tracing a route in a tunnel and monitoring the status of devices along a path using traceroute or probe application.
Therefore, before the effective filing date of the invention, it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Shi into the method by Monier and Ahearn, thereby detecting reachability of a Segment Routing version 6 (SRv6) tunnel and obtain SRv6 tunnel information of a second device in the tunnel, which helps to maintain and manage the SRv6 tunnel, Shi, [Abstract].
Regarding claim 7, Monier modified by Ahearn disclose the method according to claim 1, but did not explicitly disclose wherein the preset protocol is one of a Segment Routing IPv6 (SRV6) protocol, a Virtual Extensible Local Area Network (VXLAN) protocol, and a General Routing Encapsulation (GRE) protocol.
Shi discloses wherein the preset protocol is one of a Segment Routing IPv6 (SRV6) protocol, a Virtual Extensible Local Area Network (VXLAN) protocol, and a General Routing Encapsulation (GRE) protocol (Shi [0024] discloses a request packet used to request to detect reachability of a Segment Routing over IPv6 or a SRv6 preset tunnel network and obtain SRv6 tunnel information of the second network device, and the second network device is a network device on the SRv6 tunnel. The second network device obtains the SRv6 tunnel information of the second network device based on the request packet).
The motivation to combine is similar to that of claim 6.
Regarding claim(s) 15-16, the claim(s) is/are rejected with rational similar to that of claim(s) 6-7, respectively.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The following publications show the state of the art related to detecting the status of devices in a public network.
Arora et al. (US 2020/0351188 A1)
Arora et al. (US 10,917,337 B1)
Long et al. (US 2023/0396580 A1)
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DIXON F DABIPI whose telephone number is (571)270-3673. The examiner can normally be reached on Monday - Friday from 9:00 am to 5:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher L Parry, can be reached at telephone number 571-272-8328. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center to authorized users only. Should you have questions about access to the USPTO patent electronic filing system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
Examiner interviews are available via a variety of formats. See MPEP § 713.01. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/InterviewPractice.
/D.F.D/ Examiner, Art Unit 2451
/GLENFORD J MADAMBA/Primary Examiner, Art Unit 2451
Prosecution Insights