Prosecution Insights
Last updated: April 19, 2026
Application No. 18/406,468

PACKET TRANSMISSION METHOD, APPARATUS, AND SYSTEM, NETWORK DEVICE, AND STORAGE MEDIUM

Non-Final OA §102§103
Filed
Jan 08, 2024
Examiner
MACILWINEN, JOHN MOORE JAIN
Art Unit
2454
Tech Center
2400 — Computer Networks
Assignee
Huawei Technologies Co., Ltd.
OA Round
1 (Non-Final)
68%
Grant Probability
Favorable
1-2
OA Rounds
3y 9m
To Grant
95%
With Interview

Examiner Intelligence

Grants 68% — above average
68%
Career Allow Rate
457 granted / 676 resolved
+9.6% vs TC avg
Strong +28% interview lift
Without
With
+27.6%
Interview Lift
resolved cases with interview
Typical timeline
3y 9m
Avg Prosecution
33 currently pending
Career history
709
Total Applications
across all art units

Statute-Specific Performance

§101
8.7%
-31.3% vs TC avg
§103
53.0%
+13.0% vs TC avg
§102
11.6%
-28.4% vs TC avg
§112
18.8%
-21.2% vs TC avg
Black line = Tech Center average estimate • Based on career data from 676 resolved cases

Office Action

§102 §103
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 . Claim Rejections - 35 USC § 102 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. Claims 15, 17, and 19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Polland (WO-2014179533-A1). Regarding claim 15, Polland shows a method applied to a second network device ([42] discussing an “intermediate node 706-1”), the method comprising: receiving an internet protocol (IP) packet (([35] discussing an IPv6 packet) sent by a first network device ([42] discussing a “source node”), wherein the IP packet comprises indication information ([35,37] discussing multiple “options field header” fields, including an “enhanced route trace field”), the indication information indicates to add processing information ([22] discussing that the enhanced route trace results in “each intermediate node 106 [being] configured to insert data into the packet . . .” ) to an error packet corresponding to the IP packet ([23,58] discussing an “enhanced ICMP response” which facilitates, as noted in [47], “identifying error conditions”), and the processing information indicates a manner for processing the error packet ([56-58], discussing to “insert the relevant information in event chronological order” as well as updating various data fields); generating, in response to determining that the IP packet reaches a maximum hop count, the error packet corresponding to the IP packet, wherein the error packet comprises the processing information ([58], see “the node generates an error response containing the enhanced route trace information. . .”); and sending the error packet to the first network device, to enable the first network device to process the error packet based on the indication information ([58] . . . “and sends the error response to the source node”). Regarding claim 17, Polland shows wherein the IP packet is a user datagram protocol (UDP) packet, an internet control message protocol (ICMP) packet (Polland, [23,38,47]), or a transmission control protocol (TCP) packet. Regarding claim 19, Polland shows wherein the error packet is an internet control message protocol (ICMP) packet ( [23,38,47]). 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 for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1 – 4, 5, 12, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Polland (WO-2014179533-A1) in view of Baker (Baker, F. "IPv6 Hop-by-Hop Header Handling". draft-baker-6man-hbh-header-handling-01. (Year: 2015)). Regarding claim 1, Polland shows a method applied to a first network device ([42] discussing a “source node”), the method comprising: receiving an internet protocol (IP) packet ([35] discussing an IPv6 packet); with indication information in the IP packet ([35,37] discussing multiple “options field header” fields, including an “enhanced route trace field”); and sending the IP packet, wherein the indication information indicates to add processing information ([22] discussing that the enhanced route trace results in “each intermediate node 106 [being] configured to insert data into the packet . . .” ) to an error packet corresponding to the IP packet ([23,58] discussing an “enhanced ICMP response” which facilitates, as noted in [47], “identifying error conditions”), the processing information indicates a manner for processing the error packet ([56-58], discussing to “insert the relevant information in event chronological order” as well as updating various data fields), and the error packet is generated by a second network device ([58-59] discussing an intermediary “node” or, as described in [38], a ”destination node”) when the IP packet reaches a maximum hop count ([47,58]). Polland does not show adding the indication to a received packet. Baker shows adding an indication to a received packet (pg. 3, Sections 2.2 and 2.3 discussing “Changing options in transit” and “Adding headers or options in transit”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network diagnostic reporting techniques of Polland with the packet modifications of Baker in order to allow for packet updates while in-transit, improving overall flexibility when routing packets and communicating network status. Regarding claim 2, Polland in view of Baker further show wherein adding indication information to the IP packet comprises: adding an IPv6 extension header to the IP packet, wherein the IPv6 extension header carries the indication information (Polland, [35,56] and Baker, pg. 3). Regarding claim 3, Polland in view of Baker further show wherein the IPv6 extension header is a destination options header or a hop-by-hop options header (Polland, [35,56] and Baker, pg. 3). Regarding claim 4, Polland in view of Baker further show wherein the IPv6 extension header comprises an option field, and the option field carries the indication information (Polland, [35]). Regarding claim 5, Polland in view of Baker further show wherein the method further comprises: receiving the error packet, wherein the error packet comprises the processing information (Polland, [47-48,58]); and processing the error packet based on the processing information (Polland, [48,58], see “used to . . . identify error points”). Regarding claim 12, Polland in view of Baker further show wherein the IP packet is a user datagram protocol (UDP) packet, an internet control message protocol (ICMP) packet (Polland, [23,38,47]), or a transmission control protocol (TCP) packet. Regarding claim 14, Polland in view of Baker further show wherein the error packet is an internet control message protocol (ICMP) packet (Polland, [23,38,47]). Regarding claim 20, the limitations of said claim are rejected in the analysis of claim 1. Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Polland in view of Baker, as applied to claim 1 above, further in view of Qian (US-20060171323-A1). Regarding claim 6, Polland in view of Baker show claim 5. Polland in view of Baker do not show wherein: the processing information comprises first mode indication information, and the first mode indication information indicates that a time-to-live (TTL) mode is a pipe mode; and processing the error packet based on the processing information comprises discarding the error packet based on an indication of the first mode indication information. Qian shows wherein: the processing information comprises first mode indication information, and the first mode indication information indicates that a time-to-live (TTL) mode is a pipe mode; and processing the error packet based on the processing information comprises discarding the error packet based on an indication of the first mode indication information ([32,34,44]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network monitoring and reporting techniques of Polland in view of Baker with the TTL pipe mode use of Qian in order to ensure accurate data retrieval when operating in environments that include tunnels (such as VPNs). Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Polland in view of Baker, as applied to claim 1 above, further in view of Boutros (US-20190238364-A1). Regarding claim 11, Polland in view of Baker show wherein adding indication information to the IP packet further comprises: use of a header that comprises maximum hop count indication information (Polland, [47]). Polland in view of Baker do not show: encapsulating a tunnel header for the IP packet, wherein the tunnel header comprises maximum hop count indication information. Boutros shows: encapsulating a tunnel header for the IP packet, wherein the tunnel header comprises maximum hop count indication information ([12-13]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network monitoring and reporting techniques of Polland in view of Baker with the header data management of Boutros in order to ensure accurate data retrieval when operating in environments that include tunnels. Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Polland in view of Baker, as applied to claim 1 above, further in view of Iveson (Iveson, S. "IP Time to Live (TTL) and Hop Limit Basics". https://packetpushers.net/blog/ip-time-to-live-and-hop-limit-basics/. (Year: 2019)). Regarding claim 13, Polland in view of Baker show claim 1. Polland in view of Baker do not show: wherein the IP packet is a traceroute packet. Iveson shows wherein the IP packet is a traceroute packet (pg. 3). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network monitoring and reporting techniques of Polland in view of Baker with the traceroute use of Iveson in order to extend an existing, well-known protocol/tool (traceroute) in order to leverage existing knowledge and software that supports the existing tool. Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over in view of Qian. Regarding claim 16, Polland shows claim 15. Polland does not show: wherein the processing information comprises virtual private network (VPN) indication information or mode indication information, the VPN indication information indicates a source VPN of the IP packet, and the mode indication information indicates a time-to-live (TTL) mode corresponding to the IP packet. Qian shows wherein the processing information comprises virtual private network (VPN) indication information or mode indication information, the VPN indication information indicates a source VPN of the IP packet, and the mode indication information indicates a time-to-live (TTL) mode corresponding to the IP packet ([32,34,44]). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network monitoring and reporting techniques of Polland in view of Baker with the TTL pipe mode use of Qian in order to ensure accurate data retrieval when operating in environments that include tunnels (such as VPNs). Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Polland in view of Iveson. Regarding claim 18, Polland shows claim 15. Polland does not show: wherein the IP packet is a traceroute packet. Iveson shows wherein the IP packet is a traceroute packet (pg. 3). It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the network monitoring and reporting techniques of Polland in view of Baker with the traceroute use of Iveson in order to extend an existing, well-known protocol/tool (traceroute) in order to leverage existing knowledge and software that supports the existing tool. Allowable Subject Matter Claims 7 – 10 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Regarding claims 7 – 10, said claims further recite “VPN indication information” that corresponds to “a source network device” which is utilized when sending the error packet. While general options that facilitate processing in the presence of VPNs exist (e.g., as cited above when utilizing the Qian prior art), the particular combination of functionality required when considering claim 7 (and its dependent claims 8 – 10) as a whole (i.e., in the context provided by parent claims 5 and 1) are absent and neither taught nor suggested by the prior art of record. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. This includes: Filsfils (US-20220174011-A1), Jain (US-6795858-B1), and Sommer (Sommers, J., Barford, P. and Eriksson, B. "On the prevalence and characteristics of MPLS deployments in the open Internet." Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference. (Year: 2011)). Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN M MACILWINEN whose telephone number is (571)272-9686. The examiner can normally be reached Monday - Friday, 9:00 - 5:00. 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, Glenton B Burgess can be reached at (571) 272 - 3949. 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. JOHN MACILWINEN Primary Examiner Art Unit 2442 /JOHN M MACILWINEN/Primary Examiner, Art Unit 2454
Read full office action

Prosecution Timeline

Jan 08, 2024
Application Filed
Dec 19, 2025
Non-Final Rejection — §102, §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12603840
Secure Virtual Private Mobile and IP Network in Cloud
2y 5m to grant Granted Apr 14, 2026
Patent 12598183
CREATING GRAPHICAL MODELS OF NETWORK SECURITY POLICIES AND DISPLAYING ON A NETWORK TOPOLOGY GRAPH
2y 5m to grant Granted Apr 07, 2026
Patent 12596851
INFORMATION PROCESSING DEVICE
2y 5m to grant Granted Apr 07, 2026
Patent 12587578
SYSTEMS AND METHODS FOR PROVIDING REAL-TIME STREAMING DATA PROCESSING AT EDGE SERVERS
2y 5m to grant Granted Mar 24, 2026
Patent 12580882
ELECTRONIC MESSAGING COMMUNICATION DELIVERY METHOD
2y 5m to grant Granted Mar 17, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
68%
Grant Probability
95%
With Interview (+27.6%)
3y 9m
Median Time to Grant
Low
PTA Risk
Based on 676 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month