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 .
Response to Arguments
Applicant’s arguments, see pages 8-12 of applicant’s arguments, filed 8/04/2026 with respect to the rejection(s) of claim(s) 1, 2, 4 and 20 under Singh and claims 3, 5, 12-14 and 16-19 over Sing in view of Nainar have been fully considered and are persuasive. Therefore, the rejection has been withdrawn.
Claim Rejections - 35 USC § 112
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The term “corresponding” in claims 1, 12 and 20, line 6, line 6 and line 2, respectively, is a relative term which renders the claim indefinite. The term “corresponding” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Should the phrase “packet corresponding to” reads ---identifying---?
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being incomplete for omitting essential elements, such omission amounting to a gap between the elements. See MPEP § 2172.01. The omitted elements are:
(a) “underlay encapsulation”, line 8, is a process. Therefore, the claim fails to claim or recites the result of the “underlay encapsulation”. Should “underlay encapsulation” read ---underlay encapsulation having overhead extensions and an error data gram” ---?
(b) Claim 1, lines 6-8, reads “receive a first error packet … an underlay encapsulation”. There is no element recited in the claim for transmitting or sending “a first packet” to the “network device”. Should “receive a first packet …underlay encapsulation” read ---receive, from an intermediate device, a first error packet having an Internet Control Message Protocol (ICMP) error, wherein the first error packet comprising a first maximum transmission unit (MTU) value, an underlay encapsulation having overhead extensions and an error data gram---?
(c) Claim 1, “generate a second error packet based on the first error packet”, line 9, has missing elements of the contents of the packets. Should the phrase “generate a second error packet based on the first error packet” read --- generate a second error packet based on the first error packet, wherein the second packet comprising an inner header, an outer header and the error data gram---?
(d) Claim 1, the phrase “determine a second MTU value by extracting an error datagram from the first error packet and subtracting a length of an outer header of the extracted error datagram from the first MTU value” is confusing or unclear for the following reasons:
(1) it is not clear as to what is being considered “an outer header of the extracted error datagram”. It is a question as to whether the “error datagram” has an ---inner header---
(2) Regarding “subtracting a length of an outer header of the extracted error datagram from the first MTU value”, there is no indication that the “MTU value” is equated in ---length---. Further, there is no clear definition of” length”. It is a question as to whether “length” is referring to ---packet size---. Therefore, it is not clear as to “subtracting a length of an outer header of the extracted error datagram from the first MTU value” can be accomplished.
(3) It is not clear as to how the “first MTU value” relates to the ---length of the outer header of the extracted error datagram--- such that the “first MTU value” can be subtracted from the ---length of the outer header---.
(e) The phrase” update the second error packet with the second MTU value” is unclear or missing essential elements. The claim recites “generate a second error packet based on the first error packet”, line 9. Since no claimed content of the “second error packet” is claimed, how can “the second error packet” be updated with the “second MTU value”?
(f) Regarding “relay the second error packet including the second MTU value to a host device via an egress edge device” is confusing. If the second error packet contains the second MTU value, then relaying the second MTU error packet to the egress device would have inherently relayed the second MTU value to the egress device. The claimed limitation reads as if the “second MTU value” is appended to the “second error packet”.
(f) It is not clear as to how “egress device”, “network device” and “host device” are connectively related.
Regarding claim 11, the steps or process for determining “the second MTU value” is recited in claim 1. Claim 11 appears to be claiming a different process for determining “the second MTU value”. Thus, it is not clear as to how claim 11 is further limiting claim 1. [Note: In claim 1, the “first MTU value” does not have “an underlay encapsulation”. The limitations of claim 1 reads “receive a first error packet corresponding to an Internet Control Message Protocol (ICMP) error and comprising a first maximum transmission unit (MTU) value”]
Regarding claim 12, line 6, “receive a first error packet”, there is no element recited in the claim for transmitting or sending “a first packet” to the “network device”.
Regarding claim 12, “generate a second error packet …determined by extracting”, it is not clear as to whether “determined by extracting and error datagram from the first error datagram from the initial MTU value” is referring to the “second error packet” or the “resultant MTU value”.
Regarding claim 12, “determined by extracting an error datagram from the first error packet and subtracting a length of an outer header of the extracted error datagram from the initial MTU value” is confusing or unclear for the following reasons:
It is not clear as to what is being considered “an error datagram” in the “first error message”.
The length of the “outer header of the extracted error datagram” is not clearly defined. What is being considered “the length of the outer header of the extracted error datagram”?
It is not clear as to how to subtract a length of an outer header of the extracted error datagram from the initial MTU value.
Regarding claim 12, “update the resultant MTU value in the segment routing policy”, it is not clear as to how “the resultant MTU value” can be updated when there is no “resultant MTU value” in the segment routing policy.
Regarding claim 13, lines 2-3, “a segment routing policy”, it is not clear as to whether “a segment routing policy” is referring to “the segment routing policy” in claim 12, last line.
Regarding claim 15, “underlay encapsulation”, line 2, is a process. Therefore, the claim fails to claim or recite what is “underlay encapsulation” such that it can be transmitted and received. Further, it is not clear as to how to ---decrement a length of the underlay encapsulation from the initial MTU value.
Regarding claim 17, it is not clear as to whether “the second error packet” and “the generated second error packet” is the same packet.
Regarding claim 20, “receiving a first error packet corresponding to an Internet Control Message Protocol (ICMP) error and comprising a first maximum transmission unit (MTU) value and an underlay encapsulation”:
It is not clear as to what is “receiving a first error packet …”;
“an underlay encapsulation” is a process. The claim fails to claim or recite what is “underlay encapsulation” such that it can be transmitted and received.
Regarding claim 20, “determine a second MTU value by extracting an error datagram from the first error packet and subtracting a length of an outer header of the extracted error datagram from the first MTU value” is confusing or unclear for the following reasons:
(1) it is not clear as to what is being considered “an outer header of the extracted error datagram”. It is a question as to whether the “error datagram” has an ---inner header---
(2) Regarding “subtracting a length of an outer header of the extracted error datagram from the first MTU value”, there is no indication that the “MTU value” is equated in ---length---. Further, there is no clear definition of” length”. It is a question as to whether “length” is referring to ---packet size---. Therefore, it is not clear as to “subtracting a length of an outer header of the extracted error datagram from the first MTU value” can be accomplished.
(3) It is not clear as to how the “first MTU value” relates to the ---length of the outer header of the extracted error datagram--- such that the “first MTU value” can be subtracted from the ---length of the outer header---.
Claim 20,” updating the second error packet with the second MTU value” is unclear or missing essential elements. The claim recites “generate a second error packet based on the first error packet”. Since no claimed content of the “second error packet” is claimed, how can “the second error packet” be updated with the “second MTU value”?
Claim 20, Regarding “relaying the second error packet including the second MTU value to a host device via an egress edge device” is confusing. If the second error packet contains the second MTU value, then relaying the second MTU error packet to the egress device would have inherently relayed the second MTU value to the egress device. The claimed limitation reads as if the “second MTU value” is appended to the “second error packet”.
(f) It is not clear as to what is relaying “the second error packet” to the “egress edge device” and “host device”. Further, how are these devices convectively related?
Allowable Subject Matter
Claims 1-20 are allowable over the prior.
Conclusion
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 GLENTON B BURGESS whose telephone number is (571)272-3949. The examiner can normally be reached Monday-Friday, 8:30 am - 5:00 pm.
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.
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.
/GLENTON B BURGESS/Supervisory Patent Examiner, Art Unit 2454
