DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the America Invents Act (AIA ).
Response and Claim Status
The instant Office action is responsive to the response received July 1, 2026 (the Response).
In response to the Response, the previous rejections of claims 1–5, 7, 8, and 11–15 under 35 U.S.C. § 103
are WITHDRAWN.
Claims 1–5, 7, 8, 10–15, 17, 18, and 20–24 are currently pending.
Claim Rejections – 35 U.S.C. § 103
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–5, 11–15, 21, and 23 are rejected under 35 U.S.C. § 103 as being obvious over Chadha (US 2018/0278514 A1; filed Mar. 27, 2017) in view of Postel, RFC 792: STD 5: Internet Control Message Protocol, DARPA Internet Program Protocol Specification, pp. 1–21 (Sept. 1981)(“RFC 792”), and in further view of Kim et al. (US 2019/0182143 A1; filed Apr. 9, 2018).
Regarding claim 1, while Chadha teaches a switch controller (fig. 1, item 18; “switches . . . shown for purposes of examples as routers 18” at ¶ 20), the switch controller comprising a processor (fig. 2, item 32; “control unit 32 may include one or more processors” at ¶ 72), wherein the switch controller is configured to:
receive a packet (“At each hop, a receiving router (e.g., ‘intermediary router’) processes the traceroute packet and decrements the hop count.” at ¶ 29; fig. 4, item 400) from a sender (fig. 1, item 12), wherein the packet comprises a header (fig. 4, item 401) and a payload (fig. 4, item 412);
attempt to forward the packet through one or more ports (fig. 4, items 402, 404; “port-unreachable” at ¶ 29 at least suggests an attempt to forward the packet through a port to determine the port is unreachable);
determine that the attempt to forward the packet through one or more ports fails for at least one of the one or more ports (“When the hop count is zero, the router typically sends a response, e.g., . . . port-unreachable” at ¶ 29), and in response thereto:
determine that a header-forwarding bit (fig. 4, item 406; “a traceroute packet toward destination network device 14 with an initial hop count, e.g., a Time-to-Live (TTL) value. At each hop, a receiving router (e.g., “intermediary router”) processes the traceroute packet and decrements the hop count.” at ¶ 29) in the header is set, and in response thereto: send a response to the sender (“When the hop count is zero, the router typically sends a response, e.g., . . . port-unreachable . . . back to source network device 12 informing the source network device that the packet was received and the hop count has expired.” at ¶ 29); and
attempt to send the header (fig. 4, item 400 includes item 401) through the failed port (“Source network device 12 proceeds to send another traceroute packet with an incremented TTL value such that the traceroute packet reaches the next device in the path, and continues this process until the destination device is reached.” at ¶ 29; the Examiner emphasizes “the path” because the same routers along the path receive the packet again) in response to determining that a second header-forwarding bit is set (“an incremented TTL value such that the traceroute packet reaches the next device in the path” at ¶ 29),
Chadha does not teach (A) the response being the header of the packet; and (B) the packet being a multicast packet.
(A)
RFC 792 teaches a response (“Destination Unreachable Message” at p. 4) being a header (“Internet Header” at p. 4) of a packet (“the original datagram’s data” at p. 4).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Chadha’s response to be the header of the packet as taught by RFC 792 “to provide feedback about problems in the communication environment.” RFC 792 p. 1.
(B)
Kim teaches a multicast packet (“multicast the message to the subset of its ports.” at ¶ 37).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Chadha’s packet to be a multicast packet as taught by Kim for “ensur[ing] that the messages will eventually reach all the hosts without causing loops and generating extra messages and can significantly reduce the flooding overhead.” (¶ 38).
Regarding claim 2, while Chadha teaches wherein the switch controller is further configured to:
determine which port of the one or more ports failed (“When the hop count is zero, the router typically sends a response, e.g., . . . port-unreachable” at ¶ 29); and
include an indication of the port in a response before sending the header to the sender (“When the hop count is zero, the router typically sends a response, e.g., . . . port-unreachable . . . back to source network device 12 informing the source network device that the packet was received and the hop count has expired.” at ¶ 29 is an indication that one port failed),
Chadha does not teach the response being the header.
RFC 792 teaches a response (“Destination Unreachable Message” at p. 4) being a header (“Internet Header” at p. 4) of a packet (“the original datagram’s data” at p. 4).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Chadha’s response to be the header of the packet as taught by RFC 792 “to provide feedback about problems in the communication environment.” RFC 792 p. 1.
Regarding claim 3, while Chadha teaches wherein the switch controller is further configured to:
determine a number of how many ports of the one or more ports failed (“When the hop count is zero, the router typically sends a response, e.g., . . . port-unreachable” at ¶ 29 is an indication that one port failed); and
include an indication of the number of failed ports in a response (“When the hop count is zero, the router typically sends a response, e.g., . . . port-unreachable . . . back to source network device 12 informing the source network device that the packet was received and the hop count has expired.” at ¶ 29 is an indication that one port failed) before sending the header to the sender,
Chadha does not teach the response being the header.
RFC 792 teaches a response (“Destination Unreachable Message” at p. 4) being a header (“Internet Header” at p. 4) of a packet (“the original datagram’s data” at p. 4).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Chadha’s response to be the header of the packet as taught by RFC 792 “to provide feedback about problems in the communication environment.” RFC 792 p. 1.
Regarding claim 4, Chadha teaches wherein the switch controller is further configured to:
determine a number of hops traversed by the received multicast packet (fig. 4, item 404; “At each hop, a receiving router (e.g., “intermediary router”) processes the traceroute packet and decrements the hop count. When the hop count is zero, the router typically sends a response, e.g., TTL expired message, port-unreachable” at ¶ 29); and
include an indication of the number of hops in the header before sending the header to the sender (“Source network device 12 receives the response and configures a traceroute tree based on the response. Source network device 12 proceeds to send another traceroute packet with an incremented TTL value such that the traceroute packet reaches the next device in the path, and continues this process until the destination device is reached.” at ¶ 29).
Regarding claim 5, while Chadha teaches wherein the switch controller (fig. 1, item 18; “switches . . . shown for purposes of examples as routers 18” at ¶ 20) is further configured to set the header-forwarding bit in the header (“At each hop, a receiving router (e.g., ‘intermediary router’) processes the traceroute packet and decrements the hop count.” at ¶ 29; fig. 4, item 406) before sending a response (“When the hop count is zero, the router typically sends a response, e.g., . . . port-unreachable . . . back to source network device 12 informing the source network device that the packet was received and the hop count has expired.” at ¶ 29) to the sender to indicate that the header is a failed multicast packet header (intended use in italics),
Chadha does not teach the response being the header.
RFC 792 teaches a response (“Destination Unreachable Message” at p. 4) being a header (“Internet Header” at p. 4) of a packet (“the original datagram’s data” at p. 4).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Chadha’s response to be the header of the packet as taught by RFC 792 “to provide feedback about problems in the communication environment.” RFC 792 p. 1.
Regarding claim 11, Kim teaches a method to perform operations according to claim 1. Thus, references/arguments equivalent to those present for claim 1 are equally applicable to claim 11.
Regarding claims 12–15, claims 2–5, respectively, recite substantially similar features. Thus, references/arguments equivalent to those present for claims 2–5 are, respectively, equally applicable to claims 12–15.
Regarding claim 21, while Kim teaches wherein the header-forwarding bit (fig. 4, item 406; “a traceroute packet toward destination network device 14 with an initial hop count, e.g., a Time-to-Live (TTL) value. At each hop, a receiving router (e.g., “intermediary router”) processes the traceroute packet and decrements the hop count.” at ¶ 29) is used to notify the switch controller (fig. 1, item 18; “switches . . . shown for purposes of examples as routers 18” at ¶ 20) to send a response (“When the hop count is zero, the router typically sends a response, e.g., . . . port-unreachable . . . back to source network device 12 informing the source network device that the packet was received and the hop count has expired.” at ¶ 29) to the sender (fig. 1, item 12) upon failure of the attempt to forward the packet through the at least one of the one or more ports (“When the hop count is zero, the router typically sends a response, e.g., . . . port-unreachable” at ¶ 29),
Kim does not teach (A) the response being the header; and (B) the packet being a multicast packet.
(A)
RFC 792 teaches a response (“Destination Unreachable Message” at p. 4) being a header (“Internet Header” at p. 4) of a packet (“the original datagram’s data” at p. 4).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Chadha’s response to be the header of the packet as taught by RFC 792 “to provide feedback about problems in the communication environment.” RFC 792 p. 1.
(B)
Kim teaches a multicast packet (“multicast the message to the subset of its ports.” at ¶ 37).
It would have been obvious to one of ordinary skill in the art before the filing date of the invention for Chadha’s packet to be a multicast packet as taught by Kim for “ensur[ing] that the messages will eventually reach all the hosts without causing loops and generating extra messages and can significantly reduce the flooding overhead.” (¶ 38).
Regarding claim 23, claim 21 recites substantially similar features. Thus, references/arguments equivalent to those present for claim 21 are equally applicable to claim 23.
Allowable Subject Matter
Claims 7, 8, 10, 17, 18, 20, 22, and 24 allowed.
Conclusion
The prior art made of record and not relied upon is considered pertinent to Applicants’ disclosure: US-11558341-B2; US-20060256729-A1; US-7519006-B1; and Postel, RFC 768: User Datagram Protocol, pp. 1–4 (Sept. 1980).
Any inquiry concerning this communication or earlier communications from the Examiner should be directed to DAVID P. ZARKA whose telephone number is (703) 756-5746. The Examiner can normally be reached Monday–Friday from 9:30AM–6PM ET.
If attempts to reach the Examiner by telephone are unsuccessful, the Examiner’s supervisor, Vivek Srivastava, can be reached at (571) 272-7304. The fax phone number for the organization where this application or proceeding is assigned is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://portal.uspto.gov/external/portal. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at (866) 217-9197 (toll-free).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, Applicants are encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
/DAVID P ZARKA/PATENT EXAMINER, Art Unit 2449
Prosecution Insights