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 .
DETAILED ACTION
1. The following is a non-Final Office Action in response to applicant’s arguments/filing filed on March 11, 2026
Claims 1-17 are cancelledClaims 18-30 are pending
Response to Arguments
Applicant’s argument(s) filed on 3/11/2026 regarding 35 U.S.C.103 rejection of claim 18 and 29 have been fully considered but, in part, is not persuasive.
In the remarks, Applicant argues:a) Kim never assigns any significance to an initial fragment as such.b) Kim discloses the MTU in Kim is already known; Kim simply adjusts the sender's fragmentation size relative to that known MTU.c) Kumar in relevant part describes a management plane receiving an MTU request from an endpoint and then returning an MTU value to that requesting endpoint. That is a controller-to requester response, not a notification from the packet-receiving first communication device back to the packet-sending second communication device after receipt of an initial ESP fragment.
In regards to argument “a”, the Examiner respectfully disagrees with the Applicant. Specifically, the term, “initial fragmentation”, is not clearly defined in the claim. For instance, does the “initial fragmentation” refer to any fragment that is the first (i.e. initial) to be received? Or, does the term, “first fragment”, refer to the first fragment that is generated? The claim language is ambiguous. Therefore, under the broadest reasonable interpretation, Kim discloses the claim limitation “receiving, from a second communication device, an Encapsulating Security Payload (ESP) packet that is an initial fragment”.In regards to arguments “b” and “c”, the rejection has been fully considered and is persuasive. Therefore, the rejection is withdrawn. However, upon further consideration, a new ground of rejection is made in view of US 20150288603, Kandasamy.
Applicant’s argument(s) filed on 3/11/2026 regarding 35 U.S.C. 103 rejection of claim 22 has been fully considered and is persuasive. Therefore, the rejection is withdrawn. However, upon further consideration, a new ground of rejection is made in view of US 20150288603, Kandasamy.
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 of this title, 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.
1.) Claims 18, 19 and 29 are rejected under 35 U.S.C. 103 as being unpatentable over US 20070217424, Kim in view of US 20150288603, Kandasamy
In regards to claim 18, Kim teaches a method performed by a first communication device, comprising:receiving, from a second communication device, an Encapsulating Security Payload (ESP) packet that is an initial fragment (US 20070217424, Kim, para. 0082, in the ESP mode, the terminal 100 fragments the packet into a size of 1500 bytes and transmits the fragmented packets to the VPN gateway 200 which encrypts the packets and adds a tunnel header of 70 bytes to the packets.); Kim does not teach calculating, from the ESP packet, a Maximum Transmission Unit (MTU) in a path from the second communication device to the first communication device; notifying the second communication device of the calculated MTU; However, Kandasamy teaches calculating, from the ESP packet, a Maximum Transmission Unit (MTU) in a path from the second communication device to the first communication device(US 20150288603, Kandasamy, para. 0012,The first router generates a new path maximum transmission unit message comprising information describing the maximum acceptable packet size.); notifying the second communication device of the calculated MTU(US 20150288603, Kandasamy, para.035, At 604, a new path maximum transmission unit message is generated comprising information describing the maximum acceptable packet size. At 606, the new path maximum transmission unit message is sent to a destination network device). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kim with the teaching of Kandasamy because a user would have been motivated to use an Internet Control Message Protocol, taught by Kandasamy, to message a source device in the network taught by Kumar when a packet has exceeded a size restriction for a network path(Kandasamy, para. 0022)
In regards to 19, the combination of Kim and Kandasamy teach the method of claim 18, wherein said calculating comprises calculating the MTU as a payload length of the ESP packet(US 20070217424, Kim, para. 0083 and 0084: [0083]- Since the size of the packet with the added tunnel header exceeds the MTU size (i.e., 1500 bytes), the VPN gateway 200 re-fragments the packet, [0084]- That is, the VPN gateway 200 re-fragments the 1570-byte packet, which is made larger than the MTU due to the added tunnel header, into a 1500-byte packet and a 70-byte packet.).
In regards to claim 29, Kim teaches a first communication device comprising:a communication interface configured for communicating with a second communication device(US 20070217424, Kim, para. 0005, In a typical Internet protocol (IP) network, nodes such as terminals, routers, and the like determine the size of a maximum transmission unit (MTU) based on an interface type (e.g., Ethernet, and asynchronous transfer mode (ATM)) of a network connecting the nodes.); a memory containing instructions(US 20070217424, Kim, para. 0022, a tunnel information storage unit for storing the tunnel information;); and a processor configured to execute the instructions and thereby control the first communication device(US 20070217424, Kim, para. 0022, and a packet processor for encrypting the packet received from each terminal, ) to: receive, from the second communication device, an Encapsulating Security Payload (ESP) packet that is an initial fragment(US 20070217424, Kim, para. 0082, in the ESP mode, the terminal 100 fragments the packet into a size of 1500 bytes and transmits the fragmented packets to the VPN gateway 200 which encrypts the packets and adds a tunnel header of 70 bytes to the packets.); Kim does not teach calculate, from the ESP packet, a Maximum Transmission Unit (MTU) in a path from the second communication device to the first communication device;
notify the second communication device of the calculated MTU
However, Kandasamy teaches calculate, from the ESP packet, a Maximum Transmission Unit (MTU) in a path from the second communication device to the first communication device(US 20150288603, Kandasamy, para. 0012,The first router generates a new path maximum transmission unit message comprising information describing the maximum acceptable packet size.);
notify the second communication device of the calculated MTU(US 20150288603, Kandasamy, para.035, At 604, a new path maximum transmission unit message is generated comprising information describing the maximum acceptable packet size. At 606, the new path maximum transmission unit message is sent to a destination network device) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kim with the teaching of Kandasamy because a user would have been motivated to use an Internet Control Message Protocol, taught by Kandasamy, to message a source device in the network taught by Kumar when a packet has exceeded a size restriction for a network path(Kandasamy, para. 0022).
2.) Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over US 20070217424, Kim in view of US 20150288603, Kandasamy and further in view of US 20170353935, Xiang
In regards to claim 20, the combination of Kim and Kandasamy teach the method of claim 18. The combination of Kim and Kandasamy do not teach wherein said notifying comprises transmitting, to the second communication device, an Internet Key Exchange version 2 (IKEv2) message indicating the MTU However, Xiang teaches wherein said notifying comprises transmitting, to the second communication device, an Internet Key Exchange version 2 (IKEv2) message indicating the MTU (US 20170353935, Xiang, para. 0042, as described in further detail below, may utilize various communication protocols to establish negotiations that will adjust the MTU values of one or both gateways as needed. The two gateways, for example, may negotiate using Internet Key Exchange (e.g., IKE, RFC 2409) or Internet Key Exchange Protocol Version 2 (e.g., IKEv2, RFC 5996). ). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of the combination of Kim and Kandasamy with the teaching of Xiang because a user would have been motivated to use Internet Key Exchange, taught by Xiang, to setup negotiation between two devices, taught by the combination of Kim and Kandasamy, in order to preserve resulting security settings of the IPSec required for making secure communications(Xiang, para. 0042)
3.) Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over US 20070217424, Kim in view of US 20150288603, Kandasamy and further in view of US 20170353935, Xiang and further in view of US 202000336465, Mestery
In regards to claim 21, the combination of Kim, Kandsamy and Xiang teach the method of claim 20. the combination of Kim, Kandasamy and Xiang do not teach wherein the IKEv2 message is an IKEv2 INFORMATIONAL message However, Mestery teaches wherein the IKEv2 message is an IKEv2 INFORMATIONAL message (US 202000336465, Mestery, para. 0105, for a common IKEv2 client where the cryptographic ciphers are preconfigured (thus reducing the number of ciphers negotiated) the IKE_SA_INIT message is usually under 1000 bytes and as such is rarely fragmented at the IP layer. IKEv2 fragmentation provides the ability for IKE_AUTH traffic to be fragmented. Thus, it may be assumed that the value used for IKEv2 fragmentation may be lower than any Maximum Transmission Unit (MTU) between VPN peers and as such IKE_AUTH traffic may not be subject to IP fragmentation.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of the combination of Kim, Kandasamy and Xiang with the teaching of Mestery because a user would have been motivated to use Internet Key Exchange, taught by Mestery, to setup negotiation between two devices, taught by the combination of Kim, Kandasamy and Xiang, in order to preserve resulting security settings of the IPSec VPN required for making secure communications(Mestery, para. 0033)
4.) Claims 22, 23, 25, 26 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over US 20150288603, Kandasamy in view of US 20140101435, Kinoshita
In regards to claim 22, Kandasamy teaches a method performed by a second communication device, comprising:receiving, from a first communication device, a notification of a Maximum Transmission Unit (MTU) in a path from the second communication device to the first communication device(US 20150288603, Kandasamy, fig. 6 and para.035, At 604, a new path maximum transmission unit message is generated comprising information describing the maximum acceptable packet size. At 606, the new path maximum transmission unit message is sent to a destination network device); receiving, from a packet sender, an original Internet Protocol (IP) packet to be transmitted to the first communication device in the path(US 20150288603, Kandasamy, para. 0011, In one embodiment, at a router in a virtual private network, a packet is received from a device in a subnetwork protected by the router. The router examines the packet to determine a source address that identifies the device and a destination address that identifies a destination network device for the packet. The router also analyzes the packet to determine a size of the packet and determines whether or not the size of the packet is larger than a maximum transmission unit size. If the size of the packet is not larger than the maximum transmission unit size, the router encapsulates the packet with a header that includes the destination address and a new source address that identifies the router.); and in response to the packet size exceeding the MTU, informing the packet sender that the original packet is too big, or fragmenting the original IP packet based on the MTU(US 20150288603, Kandasamy, para. 0022, In general, PMTU techniques describe a Maximum Transmission Unit (MTU) value for a given network path before packet disruption (e.g., IP fragmentation) occurs. When the PMTU value is exceeded by a packet, one or more network devices along the network path may send to the originator of the packet an Internet Control Message Protocol (ICMP) message.); Kandasamy does not teach calculating, for the original IP packet, a packet size with an additional Encapsulating Security Payload (ESP) header and an additional tunnel header However, Kinoshita teaches calculating, for the original IP packet, a packet size with an additional Encapsulating Security Payload (ESP) header and an additional tunnel header(US 20140101435, Kinoshita, para. 0033, In step S410, the calculator 205 adds, to the value calculated in step S409, an increment corresponding to a padding field, padding length field, and next header number field which are necessary for encryption application in ESP processing. The process then advances to step S411. In step S411, only if the encapsulation mode of the SA parameters indicates a tunnel mode, the calculator 205 adds an IP header size increment to the value calculated in step S410, and terminates the process.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kandasamy with the teaching of Kinoshita because a user would have been motivated to enhance data security by enabling tunnel mode for IP packet processing, taught by Kinoshita, in order to apply authentication and encryption of IP packets used in the system taught by Kandasamy(Kinoshita, para. 0026) In regards to claim 23, the combination of Kandasamy and Kinoshita teach the method of claim 22, wherein said informing comprises transmitting, to the packet sender, an Internet Control Message Protocol (ICMP) message indicating that the original packet is too big(US 20150288603, Kandasamy, para. 0022, if a source network device sends to a group member an IP packet that is too large to traverse a network path between the group member and the destination network device, the group member may send an ICMP message back to the source network device.).
In regards to claim 25, the combination of Kandasamy and Kinoshita teach the method of claim 22, wherein the original IP packet is fragmented such that each resulting fragment, with an additional ESP header and an additional tunnel header, has a size smaller than or equal to the MTU(US 20150288603, Kandasamy, para. 0029, the packet size is sufficiently reduced such that upon encapsulation by GM A, the packet will still be sufficiently small to satisfy PMTU limits of a network path.). In regards to claim 30, Kandasamy teaches a second communication device comprising:a communication interface configured for communication with a first communication device(US 20150288603, Kandasamy, para. 0033, At 402, GM A receives a PMTU message from an “unprotected interface” (e.g., from a network device that is not in the subnetwork that GM A protects (i.e., subnet A))); a memory containing instructions(US 20150288603, Kandasamy, para. 0037, The memory 708 stores software instructions for the encapsulation software 710.); and a processor configured to execute the instructions and thereby control the second communication device(US 20150288603, Kandasamy, para. 0036, The functions of the processor 706 may be implemented by logic encoded in one or more tangible computer readable storage media or devices (e.g., storage devices compact discs, digital video discs, flash memory drives, etc. and embedded logic such as an application specific integrated circuit, digital signal processor instructions, software that is executed by a processor, etc.)), to: receive, from the first communication device, a notification of a Maximum Transmission Unit (MTU) in a path from the second communication device to the first communication device(US 20150288603, Kandasamy, fig. 6 and para.035, At 604, a new path maximum transmission unit message is generated comprising information describing the maximum acceptable packet size. At 606, the new path maximum transmission unit message is sent to a destination network device); receive, from a packet sender, an original Internet Protocol (IP) packet to be transmitted to the first communication device in the path(US 20150288603, Kandasamy, para. 0011, In one embodiment, at a router in a virtual private network, a packet is received from a device in a subnetwork protected by the router. The router examines the packet to determine a source address that identifies the device and a destination address that identifies a destination network device for the packet. The router also analyzes the packet to determine a size of the packet and determines whether or not the size of the packet is larger than a maximum transmission unit size. If the size of the packet is not larger than the maximum transmission unit size, the router encapsulates the packet with a header that includes the destination address and a new source address that identifies the router.); andin response to the packet size exceeding the MTU, inform the packet sender that the original packet is too big, or fragment the original IP packet based on the MTU(US 20150288603, Kandasamy, para. 0022, In general, PMTU techniques describe a Maximum Transmission Unit (MTU) value for a given network path before packet disruption (e.g., IP fragmentation) occurs. When the PMTU value is exceeded by a packet, one or more network devices along the network path may send to the originator of the packet an Internet Control Message Protocol (ICMP) message. ); Kandasamy does not teach calculate, for the original IP packet, a packet size with an additional Encapsulating Security Payload (ESP) header and an additional tunnel header However, Kinoshita teaches calculate, for the original IP packet, a packet size with an additional Encapsulating Security Payload (ESP) header and an additional tunnel header(US 20140101435, Kinoshita, para. 0033, In step S410, the calculator 205 adds, to the value calculated in step S409, an increment corresponding to a padding field, padding length field, and next header number field which are necessary for encryption application in ESP processing. The process then advances to step S411. In step S411, only if the encapsulation mode of the SA parameters indicates a tunnel mode, the calculator 205 adds an IP header size increment to the value calculated in step S410, and terminates the process.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Kandasamy with the teaching of Kinoshita because a user would have been motivated to enhance data security by enabling tunnel mode for IP packet processing, taught by Kinoshita, in order to apply authentication and encryption of IP packets used in the system taught by Kandasamy(Kinoshita, para. 0026)
5.) Claim 26 is rejected under 35 U.S.C. 103 as being unpatentable over US 20150288603, Kandasamy in view of US 20140101435, Kinoshita and further in view of US 20070217424, Kim In regards to claim 26, the combination of Kandasamy and Kumar teach the method of claim 25. The combination of Kinoshita and Kumar do not teach further comprising, subsequent to said fragmenting, encrypting and encapsulating each resulting fragment for transmission to the first communication device However, Kim teaches further comprising, subsequent to said fragmenting, encrypting and encapsulating each resulting fragment for transmission to the first communication device (US 20070217424, Kim, para. 0032, transmitting, by the VPN gateway, the tunnel information to each terminal when the terminal is connected via the secure network; storing, by each terminal, the tunnel information, fragmenting the packet into one of different set packet fragmentation sizes according to whether tunnel information identical to destination address information of a generated packet is stored, and transmitting the fragmented packets to the gateway; encrypting, by the VPN gateway, the packet received from the terminal, adding a tunnel header to the packet, and transmitting the resultant packet to the tunnel when the destination address information of the packet is the tunnel information of the VPN gateway;) It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of the combination of Kandasamy and Kinoshita with the teaching of Kim because a user would have been motivated to prevent a packet size from increasing geometrically by properly adjusting the packet fragmentation size of packets used in the network taught by the combination of Kinoshita and Kumar(Kim, para. 0017)
6.) Claim 24 is rejected under 35 U.S.C. 103 as being unpatentable over US 20150288603, Kandasamy in view of US 20140101435, Kinoshita and further in view of US 20020188871, Noehring
In regards to claim 24, the combination of Kandasamy and Kinoshita teach the method of claim 23. The combination of Kandasamy and Kinoshita do not teach wherein the ICMP message indicates "Destination Unreachable" with Type 3 and Code 4 for IP version 4, IPv4, or "Too Big" for IP version 6, IPv6 However, Noehring teaches wherein the ICMP message indicates "Destination Unreachable" with Type 3 and Code 4 for IP version 4, IPv4, or "Too Big" for IP version 6, IPv6 (US 20020188871, Noehring, para. 0087, The message may indicate that an ICMP PMTU message should be sent to the host with the source IP address to avoid future fragmentation. The ICMP PMTU message may convey that the destination is unreachable due to fragmentation needed and that DF set (e.g., for IPv4 packets) or due to the packet being too big (e.g., for IPv6 packets).). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of the combination of Kandasamy and Kinoshita with the teaching of Noehring because a user would have been motivated to use security association settings, taught by Noehring, in order to protect packets, in the network taught by the combination of Kandasamy and Kinoshita, from replay attacks(Noehring, para. 0048)
7.) Claim 27 is rejected under 35 U.S.C. 103 as being unpatentable over US 20150288603, Kandasamy in view of US 20140101435, Kinoshita and further in view of US 20170353935, Xiang
In regards to claim 27, the combination of Kandasamy and Kinoshita teach the method of claim 22. The combination of Kandasamy and Kinoshita do not teach wherein the notification comprises an Internet KeyExchange version 2 (IKEv2) message indicating the MTU However, Xiang teaches wherein the notification comprises an Internet KeyExchange version 2 (IKEv2) message indicating the MTU(US 20170353935, Xiang, para. 0042, as described in further detail below, may utilize various communication protocols to establish negotiations that will adjust the MTU values of one or both gateways as needed. The two gateways, for example, may negotiate using Internet Key Exchange (e.g., IKE, RFC 2409) or Internet Key Exchange Protocol Version 2 (e.g., IKEv2, RFC 5996). ). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of the combination of Kandasamy and Kinoshita with the teaching of Xiang because a user would have been motivated to use Internet Key Exchange, taught by Xiang, to setup negotiation between two devices taught by the combination of Kandasamy and Kinoshita in order to preserve resulting security settings of the IPSec required for making secure communications(Xiang, para. 0042)
8.) Claim 28 is rejected under 35 U.S.C. 103 as being unpatentable over US 20150288603, Kandasamy in view of US 20140101435, Kinoshita and further in view of US 20170353935, Xiang and further in view of US 202000336465, Mestery
In regards to claim 28, the combination of Kandasamy, Kinoshita and Xiang teach the method of claim 27. the combination of Kandasamy, Kinoshita and Xiang do not teach wherein the IKEv2 message is an IKEv2 INFORMATIONAL message. However, Mestery teaches wherein the IKEv2 message is an IKEv2 INFORMATIONAL message (US 202000336465, Mestery, para. 0105, for a common IKEv2 client where the cryptographic ciphers are preconfigured (thus reducing the number of ciphers negotiated) the IKE_SA_INIT message is usually under 1000 bytes and as such is rarely fragmented at the IP layer. IKEv2 fragmentation provides the ability for IKE_AUTH traffic to be fragmented. Thus, it may be assumed that the value used for IKEv2 fragmentation may be lower than any Maximum Transmission Unit (MTU) between VPN peers and as such IKE_AUTH traffic may not be subject to IP fragmentation.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of the combination of Kandasamy, Kinoshita and Xiang with the teaching of Mestery because a user would have been motivated to use Internet Key Exchange, taught by Mestery, to setup negotiation between two devices, taught by the combination of Kandasamy, Kinoshita and Xiang, in order to preserve resulting security settings of the IPSec VPN required for making secure communications(Mestery, para. 0033)
CONCLUSION
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY LANE whose telephone number is (571)270-7469. The examiner can normally be reached on 571 270 7469 from 8:00 AM to 6:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Taghi Arani, can be reached on 571 272 3787. 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://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/GREGORY A LANE/Examiner, Art Unit 2438
/TAGHI T ARANI/Supervisory Patent Examiner, Art Unit 2438
Prosecution Insights