CTNF 18/643,583 CTNF 93502 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Authorization for Internet Communication To expedite prosecution, filing a written authorization for internet communication is recommended. Doing so permits USPTO to communicate using email to schedule interviews and/or discuss other aspects of the application. Without the written authorization in place, USPTO cannot respond to email communications. The preferred method of providing authorization is by filing form PTO/SB/439, available at https://www.uspto.gov/patent/forms/forms. See MPEP 502.03. Claim Rejections - 35 USC § 103 07-20-aia AIA 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. 07-21-aia AIA Claim (s) 1-3 and 13-15 rejected under 35 U.S.C. 103 as being unpatentable over Kodeboyina et al. (US 2020/0313955, “Kodeboyina”) in view of Ramabadran (US 10,785,139) . Examiner’s note: in what follows, references are drawn to Kodeboyina unless otherwise mentioned. Kodeboyina comprises the following features: With respect to independent claims: Regarding claim 1 , a method, comprising: receiving, through an ingress port, a first data packet ([0062 and Fig. 5] “the ingress packets 125 are received at the ingress pipeline 110 through a set of ingress ports 545 while packets 515 that are generated by the packet generator are received at the ingress pipeline at a separate port 520.”); determining that a first forwarding path corresponding to the first data packet is faulty ([0063 and Fig. 5] “packet generator 510 receives the identification 525 of failed links.”); and sending, through the ingress port, a first notification packet ([0063] “when a forwarding element's port fails, some embodiments generate an interrupt that provides the identification of the failed port. The interrupt is used to provide the identification of the failed port to the packet generator. As another example, the packet generator may receive an identification of a failed path (such as path 215 in FIG. 2)”, and [0062] “packets 515 that are generated by the packet generator are received at the ingress pipeline at a separate port 520.” Note that sending a packet back to a port at where a faulty is determined will be discussed in view of Ramabadran.), wherein the first notification packet notifies that the first forwarding path is faulty ([0069] “the packet generator generates a packet 515 that includes the identification of the failed link in a predetermined location in the packet header.”), and wherein the first notification packet is from a data plane of a first network device ([0062] “FIG. 5 conceptually illustrates a block diagram of a hardware forwarding element 505 that is capable of marking failed links by performing a set of hardware operations in the data plane”). It is noted that while disclosing detecting a faulty path/port, Kodeboyina does not specifically teach about sending a packet to a port at where a faulty was determined. It, however, had been known in the art before the effective date of the instant application as shown by Ramabadran as follows; sending, through the ingress port ([Ramabadran, Col. 6; lines 21-22 and Fig. 10] “FIG. 6 shows the probe 520 from FIG. 5 being received on a port 610 .”, and [Ramabadran, Col. 6; lines 32-35 and Fig. 10] “The operating system responds to the error condition with a message, such as an Internet Control Message Protocol (ICMP) error message 620, that is transmitted back to network device A 120 through port 610 ”). Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify Kodeboyina by using the features of Ramabadran in order to effectively test forwarding states such that “A network switch having hardware thereon for transmitting probes to neighbor devices for exercising forwarding states (e.g., layer 2 and layer 3) on the switch.” [Ramabadran, Abstract]. Regarding claim 13 , it is a first network device claim corresponding to the method claim 1, except the limitations, “a memory configured to store instructions; and one or more processors coupled to the memory” (See Fig. 17 for “Storage”, “System Memory”, and “Processing Unit(s)”), and is therefore rejected for the similar reasons set forth in the rejection of claim 1. With respect to dependent claims: Regarding claims 2 and 14 , the method of claim 1 and the first network device of claim 13, respectively, wherein determining that the first forwarding path is faulty comprises: determining an egress port used to forward the first data packet, wherein the egress port corresponds to the first forwarding path; and determining, based on a status of the egress port, that the first forwarding path is faulty ([0067] “MAC unit 601 detects that the egress port (not shown) being monitored by the MAC unit has failed. MAC unit 601 sends a signal 660 to the port failure feedback generator 640. The port failure feedback generator 640 in turn generates a hardware signal (as conceptually shown by arrow 670) to the packet generator 611 connected to the ingress pipeline 621 and egress pipeline 631 that are associated with the failed port.”). Regarding claims 3 and 15 , the method of claim 2 and the first network device of claim 14, respectively, wherein determining that the first forwarding path is faulty further comprises: obtaining, based on a port state table of the first network device, the status; and determining, when the status is a specified state, that the first forwarding path is faulty ([0069] “The action corresponding to the match field causes a preprogrammed action unit in the forwarding element to use the failed link identification and compute an index to the status bit of the failed link in the live link vector table and to set the bit to off (i.e., to indicate that the link has failed).”) . 07-21-aia AIA Claim (s) 4 and 16 rejected under 35 U.S.C. 103 as being unpatentable over Kodeboyina et al. (US 2020/0313955, “Kodeboyina”) in view of Ramabadran (US 10,785,139) and further in view of Cherkas (US 2023/0403214) . Examiner’s note: in what follows, references are drawn to Kodeboyina unless otherwise mentioned. Regarding claims 4 and 16 , the method of claim 3 and the first network device of claim 15, respectively, further comprising: periodically reading, by using a component on the data plane, a value of a register that records the status; and updating, based on the value, the status in the port state table ([0079] “FIG. 8 conceptually illustrates a process 800 for assigning status bits to a forwarding element's egress links and programming match-action entries to set the status of a failed link to failed. Process 800 in some embodiments is performed when the hardware forwarding element is deployed and an initial set of egress links are configured. The process is also performed each time a new link is configured in order to update the match-action table.” Note that periodic reading will be discussed in view of Cherkas.). It is noted that while disclosing detecting a faulty path/port, Kodeboyina does not specifically teach about periodically reading port states. It, however, had been known in the art before the effective date of the instant application as shown by Cherkas as follows; periodically reading ([Cherkas, 0047] “the topology mapping may automatically change as a state of a construct or connection changes or upon receipt of construct metadata updates in response to certain events such as at periodic time intervals (e.g., a “dynamic topology mapping”).”). Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify Kodeboyina by using the features of Cherkas in order to effectively troubleshoot connectivity issues such that “a controller configured to deploy a first gateway in a first cloud computing network and a second gateway in a second cloud computing network” [Cherkas, Abstract] . 07-21-aia AIA Claim (s) 5 and 17 rejected under 35 U.S.C. 103 as being unpatentable over Kodeboyina et al. (US 2020/0313955, “Kodeboyina”) in view of Ramabadran (US 10,785,139) and further in view of Licking et al. (US 10,050,854, “Licking”) . Examiner’s note: in what follows, references are drawn to Kodeboyina unless otherwise mentioned. Regarding claims 5 and 17 , it is noted that while disclosing detecting a faulty path/port, Kodeboyina does not specifically teach about updating a table when no response received. It, however, had been known in the art before the effective date of the instant application as shown by Licking as follows; the method of claim 3 and the first network device of claim 15, respectively, further comprising: sending, through the egress port, at least one probe packet, wherein the at least one probe packet is from the data plane ([Licking, Col. 14; line 51] “For each BFD transmit packet that is sent out”, and [Licking, Col. 13; lines 27-30] “FIG. 11 conceptually illustrates a process 1100 that a forwarding element performs for generating and processing packets in the data plane of the forwarding element in some embodiments.”); and updating the status in the port state table to the specified state when the first network device does not receive a response packet for the at least one probe packet or for a plurality of consecutive probe packets in the at least one probe packet within a preset duration ([Licking, Col. 14; line 64 – Col. 15; line 7]). Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify Kodeboyina by using the features of Licking in order to reduce overheads such that “a hardware forwarding element with a novel packet generator that generates packets inside the forwarding element by performing a set of hardware and firmware operations in the data plane.” [Licking, Col. 1; lines 41-44] . 07-21-aia AIA Claim (s) 6 and 18 rejected under 35 U.S.C. 103 as being unpatentable over Kodeboyina et al. (US 2020/0313955, “Kodeboyina”) in view of Ramabadran (US 10,785,139) and further in view of Li (US 2013/0275529) . Examiner’s note: in what follows, references are drawn to Kodeboyina unless otherwise mentioned. Regarding claims 6 and 18 , it is noted that while disclosing detecting a faulty path/port, Kodeboyina does not specifically teach about IP address carried in a payload. It, however, had been known in the art before the effective date of the instant application as shown by Li as follows; the method of claim 1 and the first network device of claim 13, respectively, wherein the first notification packet comprises indication information and address information, wherein the indication information indicates that the first notification packet is a fault notification packet ([Li, 0061 and Fig. 4] “The mobile device bears the second notification message in a DHCP NAK packet, and sends the DHCP NAK packet to the terminal device, where the second notification message includes address information invalidation indication information and the address information corresponding to the first default bearer.”), wherein the address information is carried in a payload of the first notification packet ([Li, 0046] “The protocol packet is a DHCP NAK (Dynamic Host Configuration Protocol No Acknowledgement, dynamic host configuration protocol no acknowledgement) packet”), and wherein the address information comprises a first destination Internet Protocol (IP) address of the first data packet or an IP address prefix corresponding to the destination IP address ([Li, 0056] “a method for notifying and learning address information invalidation. The method shown in FIG. 4 is a method for notifying and learning invalidation of IPv4-type address information,”). Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify Kodeboyina by using the features of Li in order to improve flowing of data traffic such that “a method and an apparatus for notifying and learning address information invalidation” [Li, 0005] . 07-21-aia AIA Claim (s) 7 and 19 rejected under 35 U.S.C. 103 as being unpatentable over Kodeboyina et al. (US 2020/0313955, “Kodeboyina”) in view of Ramabadran (US 10,785,139) and Li (US 2013/0275529) and further in view of Zhou et al. (US 9,660,914, “Zhou”) . Examiner’s note: in what follows, references are drawn to Kodeboyina unless otherwise mentioned. Regarding claims 7 and 19 , it is noted that while disclosing detecting a faulty path/port, Kodeboyina does not specifically teach about IP address in a notification. It, however, had been known in the art before the effective date of the instant application as shown by Zhou as follows; the method of claim 6 and the first network device of claim 18, respectively, wherein a packet header of the first notification packet comprises information indicating the first data packet ([Zhou, Col. 3; lines 50-55] “Example notification messages are described in further detail below with respect to FIGS. 2-4 and 6. The destination of the notification message is set to the source of the sampled packet, and the notification message is sent to an ingress port of the L3 switch 144 through which the sampled packet was received.”), and wherein the information comprises at least one of a first source media access control (MAC) address of the first data packet, a first destination MAC address of the first data packet, a first source IP address of the first data packet, or the first destination IP address ([Zhou, Col. 5; lines 7-11] “FIG. 2 illustrates an example congestion notification message 200 for L3 networks. The example format of the message 200 may work particularly well for all non-tunneled IP traffic being sampled. The message 200 includes an IP header 210, as well as a payload 250.”). Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify Kodeboyina by using the features of Zhou in order to improve low congestion and high latency such that “method is provided for sending congestion notification messages through L3 networks” [Li, 0005] . 07-21-aia AIA Claim (s) 8 and 20 rejected under 35 U.S.C. 103 as being unpatentable over Kodeboyina et al. (US 2020/0313955, “Kodeboyina”) in view of Ramabadran (US 10,785,139), Li (US 2013/0275529) and Zhou et al. (US 9,660,914, “Zhou”), and Shmilovici et al. (US 2018/0198715, “Shmilovici”) . Examiner’s note: in what follows, references are drawn to Kodeboyina unless otherwise mentioned. Regarding claims 8 and 20 , t is noted that while disclosing detecting a faulty path/port, Kodeboyina does not specifically teach about swapping either MAC or IP addresses. It, however, had been known in the art before the effective date of the instant application as shown by Shmilovici as follows; the method of claim 7 and the first network device of claim 19, respectively, wherein the first notification packet meets at least one of the following: a second source MAC address of the first notification packet is the first destination MAC address, and a second destination MAC address of the first notification packet is the first source MAC address; or a second source IP address of the first notification packet is the first destination IP address, and a second destination IP address of the first notification packet is the first source IP address ([Shmilovici, 0044] “the egress processing module 170 modifies the header section to make the CNP packet destined to the source device. For example, the egress processing module 170 swaps values in a source IP address subfield and a destination IP address subfield in the header section.”). Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify Kodeboyina by using the features of Shmilovici in order to control traffic in congestion situations and high latency such that “to detect a congestion associated with a packet that is sent from a source device to a destination device in the network and generate a notification packet that is destined to the source device.” [Shmilovici, 0004] . 07-21-aia AIA Claim (s) 9-12 rejected under 35 U.S.C. 103 as being unpatentable over Kodeboyina et al. (US 2020/0313955, “Kodeboyina”) in view of Li (US 2013/0275529) and Ramabadran (US 10,785,139) . Examiner’s note: in what follows, references are drawn to Kodeboyina unless otherwise mentioned. Regarding claim 9 , a method, comprising: receiving, from a first network device, a first notification packet ([0063] “when a forwarding element's port fails, some embodiments generate an interrupt that provides the identification of the failed port. The interrupt is used to provide the identification of the failed port to the packet generator. As another example, the packet generator may receive an identification of a failed path (such as path 215 in FIG. 2)”, and [0062] “packets 515 that are generated by the packet generator are received at the ingress pipeline at a separate port 520.” Note that sending a packet back to a port at where a faulty is determined will be discussed in view of Ramabadran.), wherein the first notification packet notifies that a first forwarding path is faulty ([0069] “the packet generator generates a packet 515 that includes the identification of the failed link in a predetermined location in the packet header.”), wherein the first forwarding path corresponds to a first data packet ([0062 and Fig. 5] “the ingress packets 125 are received at the ingress pipeline 110 through a set of ingress ports 545 while packets 515 that are generated by the packet generator are received at the ingress pipeline at a separate port 520.”), and wherein the first network device is a downstream network device of a second network device (See aforesaid [0062] the Forwarding element of Fig. 5 is equivalent to the claimed second network device, and the one of forwarding elements in Fig. 3 could be the claimed first network device.); receiving, through an ingress port, a second data packet, wherein the second data packet and the first data packet have a same destination Internet Protocol (IP) address (This will be discussed in view of Li.); determining that a second forwarding path corresponding to the second data packet is faulty, wherein the second forwarding path comprises the first forwarding path (This will be discussed in view of Li.); and sending, through the ingress port, a second notification packet, wherein the second notification packet notifies that the second forwarding path is faulty, and wherein the second notification packet is from a data plane of the second network device (This will be discussed in view of Ramabadran.). It is noted that while disclosing detecting a faulty path/port, Kodeboyina does not specifically teach about same IP address. It, however, had been known in the art before the effective date of the instant application as shown by Li as follows; receiving, through an ingress port, a second data packet, wherein the second data packet and the first data packet have a same destination Internet Protocol (IP) address ([Li, 0061 and Fig. 4] “The mobile device bears the second notification message in a DHCP NAK packet, and sends the DHCP NAK packet to the terminal device, where the second notification message includes address information invalidation indication information and the address information corresponding to the first default bearer.”, ([Li, 0046] “The protocol packet is a DHCP NAK (Dynamic Host Configuration Protocol No Acknowledgement, dynamic host configuration protocol no acknowledgement) packet”), and ([Li, 0056] “a method for notifying and learning address information invalidation. The method shown in FIG. 4 is a method for notifying and learning invalidation of IPv4-type address information,”); determining that a second forwarding path corresponding to the second data packet is faulty, wherein the second forwarding path comprises the first forwarding path (See [Li, Fig. 5] for 405 “Parse the ICMPv6 RA packet, to obtain the address information invalidation indication information and the address information corresponding to the first default bearer”) Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify Kodeboyina by using the features of Li in order to improve flowing of data traffic such that “a method and an apparatus for notifying and learning address information invalidation” [Li, 0005]. It is noted that while disclosing detecting a faulty path/port, Kodeboyina does not specifically teach about sending a packet to a port at where a faulty was determined. It, however, had been known in the art before the effective date of the instant application as shown by Ramabadran as follows; sending, through the ingress port, a second notification packet, wherein the second notification packet notifies that the second forwarding path is faulty, and wherein the second notification packet is from a data plane of the second network device ([Ramabadran, Col. 6; lines 21-22 and Fig. 10] “FIG. 6 shows the probe 520 from FIG. 5 being received on a port 610 .”, and [Ramabadran, Col. 6; lines 32-35 and Fig. 10] “The operating system responds to the error condition with a message, such as an Internet Control Message Protocol (ICMP) error message 620, that is transmitted back to network device A 120 through port 610 ”). Therefore, it would have been obvious to one of ordinary skill in the art at the time of instant application to modify Kodeboyina by using the features of Ramabadran in order to effectively test forwarding states such that “A network switch having hardware thereon for transmitting probes to neighbor devices for exercising forwarding states (e.g., layer 2 and layer 3) on the switch.” [Ramabadran, Abstract]. Regarding claim 10 , the method of claim 9, wherein the first notification packet comprises indication information and address information, wherein the indication information indicates that the first notification packet is a fault notification packet ([Li, 0061 and Fig. 4] “The mobile device bears the second notification message in a DHCP NAK packet, and sends the DHCP NAK packet to the terminal device, where the second notification message includes address information invalidation indication information and the address information corresponding to the first default bearer.”), wherein the address information is carried in a payload of the first notification packet ([Li, 0046] “The protocol packet is a DHCP NAK (Dynamic Host Configuration Protocol No Acknowledgement, dynamic host configuration protocol no acknowledgement) packet”), and wherein the address information comprises the destination IP address or an IP address prefix corresponding to the destination IP address ([Li, 0056] “a method for notifying and learning address information invalidation. The method shown in FIG. 4 is a method for notifying and learning invalidation of IPv4-type address information,”). Regarding claim 11 , the method of claim 10, wherein after receiving the first notification packet, the method further comprises storing, on the data plane and based on the first notification packet, a correspondence between the address information and a port on which the first notification packet is received ([0040] “the parser 150 separates the packet headers from the packet payload by extracting different fields of packet headers and storing them in the PHV.”, and [0055] “when a link is down, the corresponding bit is set to off (e.g., is set to 0) to indicate that that link has failed and is not available. Vector 405 in some embodiments is stored in memory as a group of one or more words.”). Regarding claim 12 , the method of claim 11, wherein determining that the second forwarding path is faulty comprises determining, when determining that a destination address of the second data packet matches the address information and that an egress port corresponding to the second data packet is the port, that the second forwarding path is faulty ([0090] “the PHV passes through the pipeline of match and action stages 915-925. One of these match-action stages 920 is preprogrammed (e.g., as described above by reference to process 800) to match the identification of the failed link included in the PHV. The match entry 930 matches the identification of the failed link.”). Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to Harry H. Kim whose telephone number and email address are as follows; 571-272-5009, harry.kim2@uspto.gov. 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, Derrick Ferris can be reached at 571-272-3123. Information regarding the status of an application may be obtained from www.uspto.gov. For questions or assistance, 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. /HARRY H KIM/ Primary Examiner, Art Unit 2411 Application/Control Number: 18/643,583 Page 2 Art Unit: 2411 Application/Control Number: 18/643,583 Page 3 Art Unit: 2411 Application/Control Number: 18/643,583 Page 4 Art Unit: 2411 Application/Control Number: 18/643,583 Page 5 Art Unit: 2411 Application/Control Number: 18/643,583 Page 6 Art Unit: 2411 Application/Control Number: 18/643,583 Page 7 Art Unit: 2411 Application/Control Number: 18/643,583 Page 8 Art Unit: 2411 Application/Control Number: 18/643,583 Page 9 Art Unit: 2411 Application/Control Number: 18/643,583 Page 10 Art Unit: 2411 Application/Control Number: 18/643,583 Page 11 Art Unit: 2411 Application/Control Number: 18/643,583 Page 12 Art Unit: 2411 Application/Control Number: 18/643,583 Page 13 Art Unit: 2411 Application/Control Number: 18/643,583 Page 14 Art Unit: 2411 Application/Control Number: 18/643,583 Page 15 Art Unit: 2411 Application/Control Number: 18/643,583 Page 16 Art Unit: 2411 Application/Control Number: 18/643,583 Page 17 Art Unit: 2411 Application/Control Number: 18/643,583 Page 18 Art Unit: 2411
Prosecution Insights