DETAILED ACTION
This action is in response to amendments filed 2/9/2026. Claims 1-20 are pending with claims 1, 12 and 20 having been amended.
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 .
Priority
Acknowledgment is made of applicant's claim for foreign priority under 35 U.S.C. 119(a)-(d). The certified copy has been received.
Response to Arguments
Applicant's arguments filed 2/9/2026 have been fully considered.
Applicant's arguments with respect to amended claim 1,12 and 20 that Nedeltchev in view of Ammanur does not teach “constructing a second message by adding a particular header that comprises a field value configured to cause at least a part of the particular header to be treated as an Internet Protocol version 4 (IPv4) header at a beginning of the first message” have been fully considered but they are not persuasive.
Nedeltchev clearly teaches “constructing a second message by adding a particular header that comprises a field value configured to cause at least a part of the particular header to be treated as an Internet Protocol version 4 (IPv4) header at a beginning of the first message” in figure 7/8 and paragraph 0060 i.e. a new IP header1 714, an ESP header 716, an ESP trailer 718 and optional ESP authentication data 720. New IP header 1 714 is generated because with GRE inside IPsec, an IP header is included in the encrypted portion of the packet.
Since “comprises” is open ended added an a new IP header1 714 teaches the limitation “constructing a second message by adding a particular header that comprises a field value configured to cause at least a part of the particular hearder to be treated as an Internet Protocol version 4 (IPv4) header at a beginning of the first message”.
Claim Rejections - 35 USC § 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-6, 11 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Nedeltchev (US 2006/0262783) in view of Ammanur et al (US 2019/0132297).
With respect to claim 1 Nedeltchev teaches 1 a method comprising, by a first network node,
accessing a first message that is to be forwarded to a second network node after being encrypted using an Encapsulating Security Payload (ESP) encryption (See Nedeltchev paragraph 0055 i.e. In step 802, a packet is examined to identify TCP header data in the packet. For example, the packet may include a payload 706, an original TCP header 708 and an original IP header 710, as depicted in FIG. 7);
determining that an outer-most header of the first message is lack of information regarding a length of the first message; constructing a second message by adding a particular header that mimics at least a part of an Internet Protocol version 4 (IPv4) header at a beginning of the first message, wherein the particular header includes a length field indicating a combined length of the particular header and the first message (see Nedeltchev Figure 7/8 and paragraph 0060 i.e. a new IP header1 714, an ESP header 716, an ESP trailer 718 and optional ESP authentication data 720. New IP header 1 714 is generated because with GRE inside IPsec, an IP header is included in the encrypted portion of the packet);
encrypting the second message using the ESP encryption (see Nedeltchev Figure 6 step 806 and paragraph 0056 i.e. In step 806, at least a portion of the packet is encrypted using GRE inside the IPsec tunnel mode. For example, as indicated by PEP-compatible TCP/IP GRE inside IPsec packet structure 704, this causes new IP header1 714 and GRE header 712 to be generated and new IP header1 714, GRE header 712, original IP header 710, original TCP header 708, payload 706 and ESP trailer 718 to be encrypted); and
Nedeltchev does not disclose forwarding, to the second network node, the ESP encrypted second message as a user datagram protocol (UDP) packet, wherein at least a field in a UDP header of the UDP packet indicates that the second message comprises the particular header and ESP-encrypted.
Ammanur discloses forwarding, to the second network node, the ESP encrypted second message as a user datagram protocol (UDP) packet, wherein at least a field in a UDP header of the UDP packet indicates that the second message comprises the particular header and ESP-encrypted (see Ammanur paragraph 0058 i.e. The IPsec packet 420 may be encapsulated in an encapsulating packet or an outer packet (such as a UDP packet) to generate packet 400. When the IPsec packet 420 is encapsulated, the GRE IP delivery header 401 and the UDP header may be added. The GRE IP delivery header 401 and the UDP header may be used for NAT-T by the routers (and/or routing components) that transmit and/or receive the packet 400).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Nedeltchev in view of Ammanur to have encapsulate other packets (e.g., IPsec packet) within packet (e.g., an encapsulating packet, a UDP packet) to allow the routers to transmit and/or receive Network Address Translation-Traversal packets even though the routers are not behind an NAT device (see Ammanur paragraph 0058). Therefore, one would have been motivated to have encapsulate other packets (e.g., IPsec packet) within packet (e.g., an encapsulating packet, a UDP packet).
With respect to claim 2, Nedeltchev in view of Ammanur teach the method of Claim 1, wherein the first network node is an IP Security (IPsec) ingress node for the ESP encrypted second message (see Ammanur paragraph 0020 i.e. The router 110a may transmit data to and/or receive data from the router 110b via a communication channel 150. In one embodiment, the communication channel 150 may be an encrypted communication channel. An encrypted communication channel may be a channel where portions or all of the data (e.g., portions or all of the messages, packets, frames, etc.) that are transmitted/received via the channel, are encrypted. An encrypted communication channel may also be referred to as a secure communication channel. Encrypting portions or all of the data (e.g., packets) communicated via the communication channel 150 may increase or improve the security of the communication channel. Examples of encrypted communication channels include, but are not limited to, Internet Protocol Security (IPsec) channels, Transport Layer Security (TLS) channels, Secure Shell (SSH) channels, Virtual Private Network (VPN) channels, etc).
With respect to claim 3, Nedeltchev in view of Ammanur teach the method of Claim 1, wherein the second network node is an IPsec egress node for the ESP encrypted second message (see Ammanur paragraph 0020 i.e. The router 110a may transmit data to and/or receive data from the router 110b via a communication channel 150. In one embodiment, the communication channel 150 may be an encrypted communication channel. An encrypted communication channel may be a channel where portions or all of the data (e.g., portions or all of the messages, packets, frames, etc.) that are transmitted/received via the channel, are encrypted. An encrypted communication channel may also be referred to as a secure communication channel. Encrypting portions or all of the data (e.g., packets) communicated via the communication channel 150 may increase or improve the security of the communication channel. Examples of encrypted communication channels include, but are not limited to, Internet Protocol Security (IPsec) channels, Transport Layer Security (TLS) channels, Secure Shell (SSH) channels, Virtual Private Network (VPN) channels, etc).
With respect to claim 4, Nedeltchev in view of Ammanur teach the method of Claim 1, wherein the first message is an encapsulated message in accordance with a tunneling protocol (see Nedeltchev paragraph 0055 i.e. FIG. 6 is a flow diagram 600 that depicts an approach for processing a packet using PEP-compatible TCP/IP GRE inside IPsec packet structure 504 for the transport mode).
With respect to claim 5, Nedeltchev in view of Ammanur teach the method of Claim 4, wherein the particular header comprises a protocol type field indicating the tunneling protocol (see Nedeltchev paragraph 0066 i.e. FIG. 8 is a flow diagram 800 that depicts an approach for processing a packet using PEP-compatible TCP/IP GRE inside IPsec packet structure 704 for the tunnel mode, according to one embodiment of the invention).
With respect to claim 6, Nedeltchev in view of Ammanur teach the method of Claim 4, wherein the tunneling protocol comprises Virtual eXtensible Local-Area Network (VxLAN), Multiprotocol Label Switching (MPLS), Generic User Datagram Protocol Encapsulation (GUE), Generic Network Virtualization Encapsulation (GENEVE), Generic Routing Encapsulation (GRE), or Network Virtualization using GRE (NVGRE) (see Nedeltchev paragraph 0066 i.e. FIG. 8 is a flow diagram 800 that depicts an approach for processing a packet using PEP-compatible TCP/IP GRE inside IPsec packet structure 704 for the tunnel mode, according to one embodiment of the invention).
With respect to claim 11, Nedeltchev in view of Ammanur teach the method of Claim 1, wherein the at least a field in the UDP header includes a destination port number field (see Ammanur paragraph 0062 i.e. For example, the method 500 may encapsulate the encrypted packet with a UDP packet or within an NAT-T packet. In one embodiment, the method 500 may use the XFRM modules of the Linux OS to encapsulate the encrypted packet. As discussed above, encrypting the packet (to generate the encrypted packet) may prevent the source from being accessed (e.g., from being read). The method 500 may also use the routing value that is stored in the data structure (e.g., the SKB data structure) to change the source port of the encapsulating packet from a default value (e.g., 4500) to the routing value at block 525, as discussed above).
With respect to claim 20 Nedeltchev teaches a first network node comprises: one or more processors; and one or more computer-readable non-transitory storage media coupled to one or more of the processors and comprising instructions operable when executed by one or more of the processors to cause the network node to:
Access a first message that is to be forwarded to a second network node after being encrypted using an Encapsulating Security Payload (ESP) encryption (See Nedeltchev paragraph 0055 i.e. In step 802, a packet is examined to identify TCP header data in the packet. For example, the packet may include a payload 706, an original TCP header 708 and an original IP header 710, as depicted in FIG. 7);
determine that an outer-most header of the first message is lack of information regarding a length of the first message; constructing a second message by adding a particular header that mimics at least a part of an Internet Protocol version 4 (IPv4) header at a beginning of the first message, wherein the particular header includes a length field indicating a combined length of the particular header and the first message (see Nedeltchev Figure 7/8 and paragraph 0060 i.e. a new IP header1 714, an ESP header 716, an ESP trailer 718 and optional ESP authentication data 720. New IP header 1 714 is generated because with GRE inside IPsec, an IP header is included in the encrypted portion of the packet);
encrypt the second message using the ESP encryption (see Nedeltchev Figure 6 step 806 and paragraph 0056 i.e. In step 806, at least a portion of the packet is encrypted using GRE inside the IPsec tunnel mode. For example, as indicated by PEP-compatible TCP/IP GRE inside IPsec packet structure 704, this causes new IP header1 714 and GRE header 712 to be generated and new IP header1 714, GRE header 712, original IP header 710, original TCP header 708, payload 706 and ESP trailer 718 to be encrypted); and
Nedeltchev does not disclose forwarding, to the second network node, the ESP encrypted second message as a user datagram protocol (UDP) packet, wherein at least a field in a UDP header of the UDP packet indicates that the second message comprises the particular header and ESP-encrypted.
Ammanur discloses forwarding, to the second network node, the ESP encrypted second message as a user datagram protocol (UDP) packet, wherein at least a field in a UDP header of the UDP packet indicates that the second message comprises the particular header and ESP-encrypted (see Ammanur paragraph 0058 i.e. The IPsec packet 420 may be encapsulated in an encapsulating packet or an outer packet (such as a UDP packet) to generate packet 400. When the IPsec packet 420 is encapsulated, the GRE IP delivery header 401 and the UDP header may be added. The GRE IP delivery header 401 and the UDP header may be used for NAT-T by the routers (and/or routing components) that transmit and/or receive the packet 400).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Nedeltchev in view of Ammanur to have encapsulate other packets (e.g., IPsec packet) within packet (e.g., an encapsulating packet, a UDP packet) to allow the routers to transmit and/or receive Network Address Translation-Traversal packets even though the routers are not behind an NAT device (see Ammanur paragraph 0058). Therefore, one would have been motivated to have encapsulate other packets (e.g., IPsec packet) within packet (e.g., an encapsulating packet, a UDP packet).
Claims 12-16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Loughran et al (US 2006/0174108) in view of Ammanur et al (US 2019/0132297).
12. A method comprising, by a second network node:
accessing a UDP packet comprising a payload that is ESP-encrypted, wherein the payload is to be decrypted to be processed, wherein the ESP-encrypted payload includes a particular header followed by a first message, wherein the particular header comprises a field value configured to cause at least a part of the particular header to be treated as an Internet Protocol version 4 (IPv4) header, and wherein the first message is an encapsulated message in accordance with a tunneling protocol (see Loughran figure 1 and paragraph 0016 i.e. FIG. 1 of the drawings illustrates the structure of a packet which employs a tunneling protocol (specifically, L2TP) and which is to be sent over a transport protocol in a virtual private network. Such a packet is in this example intended for sending over a public network, i.e. the Internet and therefore the packet commences with an IP header 11 and an IPSec header 12. The virtual private network employs UDP as a transport protocol and L2TP (layer 2 transmission protocol) as a tunnelling protocol. This usage accounts for the UDP header 13 and the L2TP header 14. The UDP header comprises a UDP source port number 131, a UDP destination port number 132, a length field 133 and a checksum 134. The datagram represented by the UDP header, the L2TP header and a payload 15 is encapsulated by means of an IPSEC protocol and in this particular example by means of the Encapsulation Security Payload (ESP) protocol. This protocol provides authentication, data integrity and confidentiality, specifically by enciphering between an ESP header and an IPSEC authentication trailer. Currently IPSEC authentication, for both the ESP protocol in the example and the AH (Authentication Header) protocol, uses an HMAC (Hashed Message Authentication Code) which relies on a shared secret key rather than public keys; however, the type of key is not relevant to the present invention);
decrypting, using a decryption hardware, first N bits of the payload, wherein the first N bits of the payload belong to the particular header (see Loughran figure 1 and paragraph 0016 i.e. FIG. 1 of the drawings illustrates the structure of a packet which employs a tunneling protocol (specifically, L2TP) and which is to be sent over a transport protocol in a virtual private network. Such a packet is in this example intended for sending over a public network, i.e. the Internet and therefore the packet commences with an IP header 11 and an IPSec header 12. The virtual private network employs UDP as a transport protocol and L2TP (layer 2 transmission protocol) as a tunnelling protocol. This usage accounts for the UDP header 13 and the L2TP header 14. The UDP header comprises a UDP source port number 131, a UDP destination port number 132, a length field 133 and a checksum 134. The datagram represented by the UDP header, the L2TP header and a payload 15 is encapsulated by means of an IPSEC protocol and in this particular example by means of the Encapsulation Security Payload (ESP) protocol. This protocol provides authentication, data integrity and confidentiality, specifically by enciphering between an ESP header and an IPSEC authentication trailer. Currently IPSEC authentication, for both the ESP protocol in the example and the AH (Authentication Header) protocol, uses an HMAC (Hashed Message Authentication Code) which relies on a shared secret key rather than public keys; however, the type of key is not relevant to the present invention);
determining, based on a length field value within the first N bits of the payload, a length of the payload excluding an ESP trailer (see Loughran paragraph 9 i.e. The first part of the packet to be deciphered will always be the UDP header and checksum logic can latch the checksum field into a local register and paragraph 0022 i.e. Checksum verification of a UDP datagram at a receiver customarily requires the following steps: [0023] (a) add a pseudo-header to the UDP user datagram. This pseudo-header is defined by the UDP protocol and conventionally includes the IP source address, the IP destination address and transport protocol from the IP header and the length field from the UDP header; [0024] (b) add padding if needed to make data 16-bit aligned [0025] (c) divide the total bits into 16-bit sections [0026] (d) add all 16-bit sections using one's complement arithmetic [0027] (e) complement the result [0028] (f) if the result matches the checksum in the UDP header, the checksum is verified. If so, the pseudo-header and any added padding are discarded and the packet is accepted, for example for further forwarding or other processing. If not, the packet should be discarded and paragraph 0041 i.e. When it comes to the ESP trailer which can include some of the data as well as padding, a pad length and next header fields, the checksum logic will have to work out if, and so, what part of it is actual packet data. This may be done by subtracting from the length field in the IP header the length of the IPSec header; the result is the length of the packet. A simple computation then gives the number of bytes required to align the packet to 16 bits);
decrypting, using the decryption hardware, the payload based on the length of the payload excluding the ESP trailer (see Loughran paragraph (see paragraph 0041-0043 i.e. When it comes to the ESP trailer which can include some of the data as well as padding, a pad length and next header fields, the checksum logic will have to work out if, and so, what part of it is actual packet data. This may be done by subtracting from the length field in the IP header the length of the IPSec header; the result is the length of the packet...If the UDP checksum passes, all the tunnel/IPSEC headers and trailers are stripped off the packet and the raw packet is forwarded);
separating, among the payload that is decrypted, the particular header and the first message (see Loughran paragraph 0041-0043 i.e. When it comes to the ESP trailer which can include some of the data as well as padding, a pad length and next header fields, the checksum logic will have to work out if, and so, what part of it is actual packet data. This may be done by subtracting from the length field in the IP header the length of the IPSec header; the result is the length of the packet...If the UDP checksum passes, all the tunnel/IPSEC headers and trailers are stripped off the packet and the raw packet is forwarded);
determining, based on a value of a protocol type field in the particular header, the tunneling protocol (see Loughran paragraph 0017 i.e. This is done for an IPv4 packet by setting the `higher-level protocol` field (the 10.sup.th byte of the IP header) to a number which conventionally identifies the transport protocol, i.e. `50` to denote the ESP protocol); and
Loughran does not disclose determining, based on at least a field in a UDP header of the UDP packet, that the payload includes the particular header, and that the payload is ESP-encrypted (see Ammanur paragraph 0065-0066 i.e. At block 610, the method 600 determines whether the packet is an encapsulating packet, as discussed above. For example, the method 600 may determine whether the packet is a UDP packet or a NAT-T packet. If the packet is an encapsulating packet, the method 600 may obtain a routing value by accessing the source port of the encapsulating packet and may analyze the routing value at block 615. The method 600 may determine which of a plurality of processing cores should be used to process the encapsulating packet (and/or the encrypted packet within the encapsulating packet) based on the routing value, as discussed above. For example, the method 600 may map different routing values to different processing cores. At block 620, the method 600 may change the source port from the routing value, back to a default value. For example, the method 600 may change the source port from the routing value back to a default value of 4500. In some embodiments, block 620 may be optional. For example, the method 600 may not change the source port from the routing value back to the default value and may proceed to block 625); processing the first message in accordance with the tunneling protocol.
Ammanur discloses determining, based on at least a field in a UDP header of the UDP packet, that the payload includes the particular header, and that the payload is ESP-encrypted (see Ammanur paragraph 0065-0066 i.e. At block 610, the method 600 determines whether the packet is an encapsulating packet, as discussed above. For example, the method 600 may determine whether the packet is a UDP packet or a NAT-T packet. If the packet is an encapsulating packet, the method 600 may obtain a routing value by accessing the source port of the encapsulating packet and may analyze the routing value at block 615. The method 600 may determine which of a plurality of processing cores should be used to process the encapsulating packet (and/or the encrypted packet within the encapsulating packet) based on the routing value, as discussed above. For example, the method 600 may map different routing values to different processing cores. At block 620, the method 600 may change the source port from the routing value, back to a default value. For example, the method 600 may change the source port from the routing value back to a default value of 4500. In some embodiments, block 620 may be optional. For example, the method 600 may not change the source port from the routing value back to the default value and may proceed to block 625); processing the first message in accordance with the tunneling protocol (see Ammanur paragraph 0066 i.e. At block 635, the method 600 may transmit the unencrypted packet to another networking device and/or computing device (e.g., to the next hop), as discussed above).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Loughran in view of Ammanur to have encapsulate other packets (e.g., IPsec packet) within packet (e.g., an encapsulating packet, a UDP packet) to allow the routers to transmit and/or receive Network Address Translation-Traversal packets even though the routers are not behind an NAT device (see Ammanur paragraph 0058). Therefore, one would have been motivated to have encapsulate other packets (e.g., IPsec packet) within packet (e.g., an encapsulating packet, a UDP packet).
With respect to claim 13 Loughran in view of Ammanur teaches the method of Claim 12, wherein the decryption hardware treats the first N bits of the payload as a part of an IPv4 header based on contents of the first N bits (see Loughran paragraph 0016- 0017 i.e. Such a packet is in this example intended for sending over a public network, i.e. the Internet and therefore the packet commences with an IP header 11 and an IPSec header 12).
With respect to claim 14 Loughran in view of Ammanur teaches the method of Claim 12 wherein the decryption hardware discards an ESP trailer including any padding (see Loughran paragraph 9 i.e. The first part of the packet to be deciphered will always be the UDP header and checksum logic can latch the checksum field into a local register and paragraph 0022 i.e. Checksum verification of a UDP datagram at a receiver customarily requires the following steps: (a) add a pseudo-header to the UDP user datagram. This pseudo-header is defined by the UDP protocol and conventionally includes the IP source address, the IP destination address and transport protocol from the IP header and the length field from the UDP header; (b) add padding if needed to make data 16-bit aligned (c) divide the total bits into 16-bit sections (d) add all 16-bit sections using one's complement arithmetic (e) complement the result (f) if the result matches the checksum in the UDP header, the checksum is verified. If so, the pseudo-header and any added padding are discarded and the packet is accepted, for example for further forwarding or other processing. If not, the packet should be discarded and paragraph 0041 i.e. When it comes to the ESP trailer which can include some of the data as well as padding, a pad length and next header fields, the checksum logic will have to work out if, and so, what part of it is actual packet data. This may be done by subtracting from the length field in the IP header the length of the IPSec header; the result is the length of the packet. A simple computation then gives the number of bytes required to align the packet to 16 bits).
With respect to claim 15 Loughran in view of Ammanur teaches the method of Claim 12 wherein the second network node is an IPsec egress node for the payload (see Ammanur paragraph 0020 i.e. The router 110a may transmit data to and/or receive data from the router 110b via a communication channel 150. In one embodiment, the communication channel 150 may be an encrypted communication channel. An encrypted communication channel may be a channel where portions or all of the data (e.g., portions or all of the messages, packets, frames, etc.) that are transmitted/received via the channel, are encrypted. An encrypted communication channel may also be referred to as a secure communication channel. Encrypting portions or all of the data (e.g., packets) communicated via the communication channel 150 may increase or improve the security of the communication channel. Examples of encrypted communication channels include, but are not limited to, Internet Protocol Security (IPsec) channels, Transport Layer Security (TLS) channels, Secure Shell (SSH) channels, Virtual Private Network (VPN) channels, etc).
With respect to claim 16 Loughran in view of Ammanur teaches the method of Claim 12, wherein the tunneling protocol comprises Virtual eXtensible Local-Area Network (VxLAN), Multiprotocol Label Switching (MPLS), Generic User Datagram Protocol Encapsulation (GUE), Generic Network Virtualization Encapsulation (GENEVE), Generic Routing Encapsulation (GRE), or Network Virtualization using GRE (NVGRE) (see Loughran figure 1 and paragraph 0016 i.e. FIG. 1 of the drawings illustrates the structure of a packet which employs a tunneling protocol (specifically, L2TP) and which is to be sent over a transport protocol in a virtual private network. Such a packet is in this example intended for sending over a public network, i.e. the Internet and therefore the packet commences with an IP header 11 and an IPSec header 12. The virtual private network employs UDP as a transport protocol and L2TP (layer 2 transmission protocol) as a tunnelling protocol. This usage accounts for the UDP header 13 and the L2TP header 14. The UDP header comprises a UDP source port number 131, a UDP destination port number 132, a length field 133 and a checksum 134. The datagram represented by the UDP header, the L2TP header and a payload 15 is encapsulated by means of an IPSEC protocol and in this particular example by means of the Encapsulation Security Payload (ESP) protocol. This protocol provides authentication, data integrity and confidentiality, specifically by enciphering between an ESP header and an IPSEC authentication trailer. Currently IPSEC authentication, for both the ESP protocol in the example and the AH (Authentication Header) protocol, uses an HMAC (Hashed Message Authentication Code) which relies on a shared secret key rather than public keys; however, the type of key is not relevant to the present invention).
With respect to claim 19 Loughran in view of Ammanur teaches the method of Claim 12, wherein the at least a field in the UDP header includes a destination port number field (see Ammanur paragraph 0062 i.e. For example, the method 500 may encapsulate the encrypted packet with a UDP packet or within an NAT-T packet. In one embodiment, the method 500 may use the XFRM modules of the Linux OS to encapsulate the encrypted packet. As discussed above, encrypting the packet (to generate the encrypted packet) may prevent the source from being accessed (e.g., from being read). The method 500 may also use the routing value that is stored in the data structure (e.g., the SKB data structure) to change the source port of the encapsulating packet from a default value (e.g., 4500) to the routing value at block 525, as discussed above).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Nedeltchev (US 2006/0262783) in view of Ammanur et al (US 2019/0132297) in view of Rangarajan et al (US 2025/0211505).
With respect to claim 7 Nedeltchev in view of Ammanur teaches the method of Claim 1, but do not disclose wherein the particular header is a modified GRE header, wherein the particular header comprises 64 bits.
Rangarajan teaches wherein the particular header is a modified GRE header, wherein the particular header comprises 64 bits (see Rangarajan paragraph 0036 FIG. 3 depicts the standard GRE header format (reference numeral 300) per RFC 2784, which spans 8 bytes (64 bits) and paragraph 0036 i.e. Finally, non-standard GRE header format 800 depicted in FIG. 8 is a non-expanded format, or in other words a format that is the same size as the standard GRE header format depicted in FIG. 3).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have further modify Nedeltchev and Ammanur in view of Rangarajan to have used a non-standard GRE header format that is the same number of bits as the standard GRE header format that allows allows all three of these monitoring-related metadata to be included in the GRE header without expanding its size beyond 64 bits (see Rangarajan paragraph 0036). Therefore one would have been motivated to have used a non-standard GRE header format.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Loughran et al (US 2006/0174108) in view of Ammanur et al (US 2019/0132297) in view of Rangarajan et al (US 2025/0211505).
With respect to claim 17 Nedeltchev in view of Ammanur teaches the method of Claim 12, but do not disclose wherein the particular header is a modified GRE header, wherein the particular header comprises 64 bits.
Rangarajan teaches wherein the particular header is a modified GRE header, wherein the particular header comprises 64 bits (see Rangarajan paragraph 0036 FIG. 3 depicts the standard GRE header format (reference numeral 300) per RFC 2784, which spans 8 bytes (64 bits) and paragraph 0036 i.e. Finally, non-standard GRE header format 800 depicted in FIG. 8 is a non-expanded format, or in other words a format that is the same size as the standard GRE header format depicted in FIG. 3).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have further modify Nedeltchev and Ammanur in view of Rangarajan to have used a non-standard GRE header format that is the same number of bits as the standard GRE header format that allows allows all three of these monitoring-related metadata to be included in the GRE header without expanding its size beyond 64 bits (see Rangarajan paragraph 0036). Therefore one would have been motivated to have used a non-standard GRE header format.
Allowable Subject Matter
Claims 8-10 and 18 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.
With respect to claim 8 the prior art does not teach the method of Claim 7, wherein first four bits of the particular header comprise a bit stream of ‘0100’.
With respect to claim 9 the prior art does not teach the method of Claim 7, wherein a version field of the particular header indicates one.
With respect to claim 10 the prior art does not teach the method of Claim 7, wherein a reserved field of the particular header is filled with ones.
With respect to claim 18 the prior art does not teach the method of Claim 12, wherein a reserved field of the particular header is filled with ones, and wherein the second network node determines that the particular header needs to be discarded based at least on the reserved field.
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 DEVIN E ALMEIDA whose telephone number is (571)270-1018. The examiner can normally be reached on Monday-Thursday from 7:30 A.M. to 5:00 P.M. The examiner can also be reached on alternate Fridays from 7:30 A.M. to 4:00 P.M.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Rupal Dharia, can be reached on 571-272-3880. 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).
/DEVIN E ALMEIDA/Examiner, Art Unit 2492 /RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492