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 .
This office action is in response to Applicant’s communication filed on 03/27/2026. Claims 21-40 have been examined. Claims 1-20 are cancelled.
Response to Arguments
Applicant’s arguments, see Remarks – Pages 9-11, filed on 03/27/2026, with respect to the rejections of claims 21,28,35 under 103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Cisco.
With regards to claim objection , Applicant’s amendment overcome the objection. Therefore, the objection is withdrawn.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
With regards to Patent No. 12,068,886 B2
Claims 21-40 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-20 of Patent No. US 12,068,886 B2 in view of Cisco.
Although the conflicting claims are not identical, they are not patentably distinct from each other because:
See Below for analysis
Claims 21- 40 of Instant application
Claims 1-20 of Patent No. 12,068,886
Claims 21,28,35
A first network element/method/medium comprising one or more processors and one or more computer-readable non-transitory storage media coupled to the one or more processors and including instructions that, when executed by the one or more processors, cause the first network element to perform operations comprising:
configuring an Internet Protocol version 4 (IPv4) over IPv6 tunnel between the first network element and a second network element;
configuring a loopback interface;
assigning the loopback interface an IPv4 address;
configuring an overlay tunnel using the loopback interface; and
binding the overlay tunnel to the IPv4 over IPv6 tunnel.
Claims 1,8,15
A first network element/method/medium comprising one or more processors and one or more computer-readable non-transitory storage media coupled to the one or more processors and including instructions that, when executed by the one or more processors, cause the first network element to perform operations comprising:
acquiring an Internet Protocol version 6 (IPv6) address for a physical interface of the first network element;
configuring an Internet Protocol version 4 (IPv4) over IPv6 tunnel between the first network element and a second network element using the physical interface of the first network element;
acquiring an updated IPv6 address for the physical interface of the first network element; using an IPv6 Service Level Agreement (SLA) Hypertext Transfer Protocol (HTTP) operation to notify the second network element of the updated IPv6 address to establish a bidirectional IPv4 over IPv6 tunnel; configuring a loopback interface; assigning the loopback interface an IPv4 address; configuring an overlay tunnel using the loopback interface, wherein the overlay tunnel is a software-defined wide area network(SD-WAN) overlay tunnel; and binding the SD-WAN overlay tunnel to the IPv4 over IPv6 tunnel.
Claims 22,29,36
communicating with an IPv4 controller via the IPv4 over IPv6 tunnel, wherein the IPv4 over IPv6 tunnel is a bidirectional IPv4 over IPv6 tunnel of an underlay network; establishing a control connection with the IPv4 controller; and automatically building the overlay tunnel with the bidirectional IPv4 over IPv6 tunnel as a transport..
Claims 2,9,16
communicating with an IPv4 SD-WAN controller via the bidirectional IPv4 over IPv6 tunnel of an underlay network; establishing a control connection with the IPv4 SD-WAN controller; and automatically building the SD-WAN overlay tunnel with the bidirectional IPv4 over IPv6 tunnel as a transport.
Claims 23,30,37
configuring network address translation (NAT) on the loopback interface of the IPv4 over IPv6 tunnel; receiving an IPv4 packet from a host, wherein the IPv4 packet comprises a service-side source IPv4 address and a destination IPv4 address; translating, using NAT, the service-side source IPv4 address to a public IPv4 address; encapsulating the IPv4 packet within an IPv6 packet; and communicating, via the IPv4 over IPv6 tunnel, the IPv4 packet to the second network element.
Claims 3,10,17
configuring network address translation (NAT) on the loopback interface of the IPv4 over IPv6 tunnel; receiving an IPv4 packet from a host, wherein: the IPv4 packet comprises a service-side source IPv4 address and a destination IPv4 address; and the destination IPv4 address is associated with a remote SD-WAN site; translating, using NAT, the service-side source IPv4 address to a public IPv4 address; encapsulating the IPv4 packet within an IPv6 packet; and communicating, via the bidirectional IPv4 over IPv6 tunnel, the IPv4 packet to the second network element.
Claims 24,31,38
acquiring an IPv6 address for a physical interface of the first network element, wherein the physical interface is used to configure the IPv4 over IPv6 tunnel between the first network element and the second network element;
acquiring an updated IPv6 address for the physical interface of the first network element; and using an IPv6 Service Level Agreement (SLA) Hypertext Transfer Protocol (HTTP) operation to notify the second network element of the updated IPv6 address to establish a bidirectional IPv4 over IPv6 tunnel.
Claims 1,8,15
acquiring an Internet Protocol version 6 (IPv6) address for a physical interface of the first network element;
configuring an Internet Protocol version 4 (IPv4) over IPv6 tunnel between the first network element and a second network element using the physical interface of the first network element;
acquiring an updated IPv6 address for the physical interface of the first network element; using an IPv6 Service Level Agreement (SLA) Hypertext Transfer Protocol (HTTP) operation to notify the second network element of the updated IPv6 address to establish a bidirectional IPv4 over IPv6 tunnel; configuring a loopback interface…..
Claims 25,32.39
wherein the IPv6 address of the physical interface is automatically assigned by a Dynamic Host Configuration Protocol version 6 (DHCPv6) server or by an IPv6 auto-configuration.
Claims 6,13,20
wherein: the IPv6 address of the physical interface is automatically assigned by a Dynamic Host Configuration Protocol version 6 (DHCPv6) server or by an IPv6 auto-configuration; and the IPv4 address of the loopback interface is provided by a service provider..
Claims 26,33,40
wherein the IPv4 address of the loopback interface is provided by a service provider.
Claims 6,13.20
…the IPv4 address of the loopback interface is provided by a service provider..
Claims 27,34
wherein: the first network element is an edge router; and the second network element is an IPv6 border router.
Claims 7,14
wherein: the first network element is an SD-WAN edge router; and the second network element is a general IPv6 border router.
With regards to claim 21,28,35, the Patent No. US 12,068,886 B2 does not explicitly teach wherein each endpoint of the overlay tunnel is uniquely identified by a Transport Location (TLOC) , represented by a combination of an IP address, a color and an encapsulation.
However, Cisco teaches wherein each endpoint of the overlay tunnel is uniquely identified by a Transport Location (TLOC) , represented by a combination of an IP address, a color and an encapsulation (Section - TLOC Attributes Used in Policies, Section - TLOC Attributes Used in Policies &Section Centralized Control Policy Configuration Examples ).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Patent No. US 12,068,886 B2 to include the teachings of Cisco. The motivation to do so is to allow the system to use TLOC routes in order to carry properties associated with Transport locations which are physical point at which the devices connect to the WAN or transport network ( Cisco – Section – Route Types).
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 21,22,28,29,35,36 are rejected under 35 U.S.C. 103 as being unpatentable over Tamizkar et al. Publication No. US 2021/0105209 A1 (Tamizkar hereinafter) in view of Cisco et al. “Policies Configuration Guide for vEdge Routers, Cisco SD-WAN Releases 19.1, 19.2, and 19.3 “ 12/24/2019 (Cisco hereinafter) further in view of Khalid et al. Publication No. US 2010/0085977 A1 ( Khalid hereinafter)
Regarding claim 21,
Tamizkar teaches a first network element comprising,
one or more processors and one or more computer-readable non-transitory storage media coupled to the one or more processors and including instructions that, when executed by the one or more processors, cause the first network element ( (Figs.4 -6) to perform operations comprising:
configuring a loopback interface (¶ 0026 - configuring a first loopback interface and assigning an internal Virtual Route Forwarder (VRF) to the first loopback interface; configuring a second loopback interface and assigning an internal Virtual Route Forwarder (VRF2) to the second loopback interface – For the first GRE tunnel, assigning the first loopback interface as a source point of the first GRE tunnel and assigning the second loopback interface as a destination point of the first GRE tunnel – ¶ 0047 - Creating/configuring Loopback 1 107 A and assigning to internal VRF 107 ( or first VRF) and creating or configuring Loopback 2 (or LB2) 108A and assigning to internal VRF2 108 ( or second VRF) in Router R1 101 – R1# - Interface Loopback 1 // create loopback interface).
assigning the loopback interface an IPv4 address (¶0047 – IP address 20.20.20.1/24 \\ assign IP address to Loopback 1 - ¶ 0048 - The IP addresses of Loopback 107A and Loopback2 108A are in different subnets i.e.: (0049] Subnet-1 20.20.20.0/24 for Loopback (or LBl) having IP address 20.20.20.1/24 (0050] Subnet-2 30.30.30.0/24 for Loopback2 (or LB2) having IP address 30.30.30.1/24 (0051] It must be noted that the IP address or addresses 20.20.20.1/24 and 30.30.30.1 /24 or the subnets 20.20.20.0/ 24 and 30.30.30.0/24 are only examples.
configuring an overlay tunnel using the loopback interface (¶ 0059 - for the first GRE tunnel (Tunnel) 107B we assign the first loopback interface (Loopback) 107A as a source point of Tunnel and we assign the second loop back interface (Loopback2) 108A as a destination point of Tunnel. ¶ 0060 Similarly, for the second GRE tunnel (Tunnel2) 108B, we assign the second loopback interface (Loopback2 or LB2) 108A as a source point of Tunnel2 and assign the first loopback interface (Loopback) 107A as a destination point ofTunnel2. This is shown in the following configuration: (0061] 4) Define tunnel source and destination in R1 – ¶ 0062 - interface Tunnel Ip VRF forwarding VRF IP address 10.10.10.1/24 tunnel source Loopback tunnel destination 30.30.30.1 interface Tunnel2 IP VRF forwarding VRF2 IP address 10.10.10.2/24 tunnel source Loopback2 tunnel destination 20.20.20.1).
However, Tamizkar does not explicitly teach
wherein each endpoint of the overlay tunnel is uniquely identified by a Transport Location (TLOC) , represented by a combination of an IP address, a color and an encapsulation
configuring an Internet Protocol version 4 (IPv4) over Internet Protocol version 6 (IPv6) tunnel between the first network element and a second network element and binding the overlay tunnel to the IPv4 over IPv6 tunnel.
Cisco teaches
each endpoint of the overlay tunnel is uniquely identified by a Transport Location (TLOC) , represented by a combination of an IP address, a color and an encapsulation ( Section – TLOC Attributes Used in Policies – At transport location, or TLOC, defines a specific interface in the overlay network. Each TLOC consists of a set of attributes that are exchanged in OMP updates among the Cisco IOS XE Catalyst SD-WAN devices. Each TLOC is uniquely identified by a 3-tuple of IP address, color, and encapsulation – Section -Control Policy – TLOC routes carry overlay network–specific locator properties, including the IP address of the interface that connects to the transport network, a link color, which identifies a traffic flow, and the encapsulation type. (A TLOC, or transport location, is the physical location where a Cisco vEdge device connects to a transport network. It is identified primarily by IP address, link color, and encapsulation, but a number of other properties are associated with a TLOC – See Also Section Centralized Control Policy Configuration Examples.)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar to include the teachings of Cisco. The motivation to do so is to allow the system to use TLOC routes in order to carry properties associated with Transport locations which are physical point at which the devices connect to the WAN or transport network ( Cisco – Section – Route Types).
Khalid teaches
configuring an Internet Protocol version 4 (IPv4) over IPv6 tunnel between the first network element and a second network element and binding the overlay tunnel to the IPv4 over IPv6 tunnel (Fig.1, ¶ 0007 -. FIG. 1 is a block diagram of a Dynamic Multipoint Virtual Private Network (DMVPN) running on IPv4 technology over an IPv6 cloud for practicing one or more embodiments of the present disclosure; ¶ 0013 - Each multipoint tunnel in particular embodiments may be defined to include an IPv4 address as the tunnel IP address, andanIPv6 address as the tunnel source IP address. In particular embodiments, the tunnel source IPv6 address may be used as the source IPv6 address of the IPv6 packet transmitted towards the Hub or Spoke site via the IPv6 cloud. In particular embodiments, the multipoint tunnel may employ generic routing encapsulation (GRE) – ¶ 0005 - establishing an Internet Protocol version Six (IPv6) multipoint
tunnel with an IPv6 address as a tunnel source address and an Internet Protocol version Four (IPv4) as a tunnel address, between a first spoke router and a hub router, transmitting a binding information associated with the first spoke router by the hub router to the second spoke router, forwarding an IPv4 data packet from the first spoke router to the second spoke router over the IPv6 multipoint tunnel via the hub router, and establishing a direct communication path between the second spoke router and the first spoke router using the binding information associated with the first spoke router- See ¶ 0032-¶ 0033, Claim 7, ¶ 0016).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar to include the teachings of Khalid. The motivation to do so is to allow the system to provide a framework for optimized connectivity of an IPv4 Dynamic Multipoint Virtual Private Network over an IPv6 Internet Protocol/Multiprotocol Label Switching cloud (Khalid – ¶ 0001).
Regarding claim 22.
Tamizkar does not explicitly teach
communicating with an IPv4 controller via the IPv4 over IPv6 tunnel, wherein the IPv4 over IPv6 tunnel is a bidirectional IPv4 over IPv6 tunnel of an underlay network; establishing a control connection with the IPv4 controller; and automatically building the overlay tunnel with the bidirectional IPv4 over IPv6 tunnel as a transport.
However, Khalid teaches
communicating with an IPv4 controller via the IPv4 over IPv6 tunnel, wherein the IPv4 over IPv6 tunnel is a bidirectional IPv4 over IPv6 tunnel of an underlay network (¶ 0006 - A method in particular embodiments includes registering a first spoke router with a hub router, forwarding an Internet Protocol version Four (IPv4) data packet from the first spoke router to a second spoke router over an Internet Protocol version Six (IPv6) multipoint tunnel via the hub router, transmitting a binding information associated with the first spoke router from the hub router to the second spoke- ¶ 0013 -Referring again to FIG. 1, in particular embodiments, data packets may be transmitted either between the hub site 120 (Ipv4 controller), and the spokes 130, 140, or between spoke A 130 and spoke B 140, over the IPv6 cloud 110, via the multipoint tunnels 112-115. Each multipoint tunnel in particular embodiments may be defined to include an IPv4 address as the tunnel IP address, andanIPv6 address as the tunnel source IP address. In particular embodiments, the tunnel source IPv6 address may be used as the source IPv6 address of the IPv6 packet transmitted towards the Hub or Spoke site via the IPv6 cloud – ¶ 0022 - To connect to spoke A 130, in particular embodiments, the hub site 120 receives a null packet from spoke A 130 that includes the encrypted registration extension header (310). This extension header 310 may be sent through the IPv6 multipoint tunnel over the IPv6 cloud, and includes the IPv4 tunnel address and IPv6 address of spoke A 130).
establishing a control connection with the IPv4 controller (¶ 0015 - the extension header may encode spoke A's 130 IPv4 tunnel address and spoke A's 130 IPv6 address, which is used for reachability over the IPv6 network – ¶ 0022 - To connect to spoke A 130, in particular embodiments, the hub site 120 receives a null packet from spoke A 130 that includes the encrypted registration extension header (310). This extension header 310 may be sent through the IPv6 multipoint tunnel over the IPv6 cloud includes the IPv4 tunnel address and IPv6 address of spoke A 130. The hub site 120 may decrypt the encapsulated extension headers using the group key, and then respond with an acknowledgment to spoke A 130 through the IPv6 multipoint tunnels, including an extension header, also encrypted with the group key, encoding the IPv6 tunnel source address and the IPv4 tunnel address of the hub site 120 (320). In particular embodiments, the hub site 120 may update the binding table with spoke A 130, to register spoke A 130 with the hub site 120 and establishing a connection).
automatically building the overlay tunnel with the bidirectional IPv4 over IPv6 tunnel as a transport (Abstract - and establishing a direct communication path by the second spoke router with the first spoke route based on the received binding information are provided – ¶ 0006 - establishing a direct communication path by the second spoke router with the first spoke router based on the received binding information – ¶ 0019 - Upon receiving and decrypting the new binding information encoded within the extension header sent from spoke B 140, spoke A 130 will update its own binding information, thus creating a direct connection tunnel
115 between spoke A 130 and spoke B 140 over the IPv6 cloud 110, without needing to send traffic via a hub site 120. In this manner, in particular embodiments, using the IPv6 functionalities, the previously required next hop resolution protocol (NHRP) is no longer needed in DMVPN for the next-hop resolution related to each spoke site network entity, device or router).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar to include the teachings of Khalid. The motivation to do so is to allow the system to provide a framework for optimized connectivity of an IPv4 Dynamic Multipoint Virtual Private Network over an IPv6 Internet Protocol/Multiprotocol Label Switching cloud (Khalid – ¶ 0001).
Regarding claim 28,
Tamizkar teaches a method comprising,
configuring a loopback interface ( ¶ 0026 - configuring a first loopback interface and assigning an internal Virtual Route Forwarder (VRF) to the first loopback interface; configuring a second loopback interface and assigning an internal Virtual Route Forwarder (VRF2) to the second loopback interface – For the first GRE tunnel, assigning the first loopback interface as a source point of the first GRE tunnel and assigning the second loopback interface as a destination point of the first GRE tunnel – ¶ 0047 - Creating/configuring Loopback 1 107 A and assigning to internal VRF 107 ( or first VRF) and creating or configuring Loopback 2 (or LB2) 108A and assigning to internal VRF2 108 ( or second VRF) in Router R1 101 – R1# - Interface Loopback 1 // create loopback interface);
assigning the loopback interface an IPv4 address (¶0047 – IP address 20.20.20.1/24 \\ assign IP address to Loopback 1 - ¶ 0048 - The IP addresses of Loopback 107A and Loopback2 108A are in different subnets i.e.: (0049] Subnet-1 20.20.20.0/24 for Loopback (or LBl) having IP address 20.20.20.1/24 (0050] Subnet-2 30.30.30.0/24 for Loopback2 (or LB2) having IP address 30.30.30.1/24 (0051] It must be noted that the IP address or addresses 20.20.20.1/24 and 30.30.30.1 /24 or the subnets 20.20.20.0/ 24 and 30.30.30.0/24 are only examples.
configuring an overlay tunnel using the loopback interface (¶ 0059 - for the first GRE tunnel (Tunnel) 107B we assign the first loopback interface (Loopback) 107A as a source point of Tunnel and we assign the second loop back interface (Loopback2) 108A as a destination point of Tunnel. ¶ 0060 Similarly, for the second GRE tunnel (Tunnel2) 108B, we assign the second loopback interface (Loopback2 or LB2) 108A as a source point of Tunnel2 and assign the first loopback interface (Loopback) 107A as a destination point ofTunnel2. This is shown in the following configuration: (0061] 4) Define tunnel source and destination in R1 – ¶ 0062 - interface Tunnel Ip VRF forwarding VRF IP address 10.10.10.1/24 tunnel source Loopback tunnel destination 30.30.30.1 interface Tunnel2 IP VRF forwarding VRF2 IP address 10.10.10.2/24 tunnel source Loopback2 tunnel destination 20.20.20.1).
However, Tamizkar does not explicitly teach
wherein each endpoint of the overlay tunnel is uniquely identified by a Transport Location (TLOC) , represented by a combination of an IP address, a color and an encapsulation
configuring an Internet Protocol version 4 (IPv4) over Internet Protocol version 6 (IPv6) tunnel between the first network element and a second network element and binding the overlay tunnel to the IPv4 over IPv6 tunnel.
Cisco teaches
wherein each endpoint of the overlay tunnel is uniquely identified by a Transport Location (TLOC) , represented by a combination of an IP address, a color and an encapsulation ( Section – TLOC Attributes Used in Policies – At transport location, or TLOC, defines a specific interface in the overlay network. Each TLOC consists of a set of attributes that are exchanged in OMP updates among the Cisco IOS XE Catalyst SD-WAN devices. Each TLOC is uniquely identified by a 3-tuple of IP address, color, and encapsulation – Section -Control Policy – TLOC routes carry overlay network–specific locator properties, including the IP address of the interface that connects to the transport network, a link color, which identifies a traffic flow, and the encapsulation type. (A TLOC, or transport location, is the physical location where a Cisco vEdge device connects to a transport network. It is identified primarily by IP address, link color, and encapsulation, but a number of other properties are associated with a TLOC - See Also Section Centralized Control Policy Configuration Examples.)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar to include the teachings of Cisco. The motivation to do so is to allow the system to use TLOC routes in order to carry properties associated with Transport locations which are physical point at which the devices connect to the WAN or transport network ( Cisco – Section – Route Types).
Khalid teaches
configuring an Internet Protocol version 4 (IPv4) over IPv6 tunnel between the first network element and a second network element and binding the overlay tunnel to the IPv4 over IPv6 tunnel (Fig.1, ¶ 0007 -. FIG. 1 is a block diagram of a Dynamic Multipoint Virtual Private Network (DMVPN) running on IPv4 technology over an IPv6 cloud for practicing one or more embodiments of the present disclosure; ¶ 0013 - Each multipoint tunnel in particular embodiments may be defined to include an IPv4 address as the tunnel IP address, andanIPv6 address as the tunnel source IP address. In particular embodiments, the tunnel source IPv6 address may be used as the source IPv6 address of the IPv6 packet transmitted towards the Hub or Spoke site via the IPv6 cloud. In particular embodiments, the multipoint tunnel may employ generic routing encapsulation (GRE) – ¶ 0005 - establishing an Internet Protocol version Six (IPv6) multipoint
tunnel with an IPv6 address as a tunnel source address and an Internet Protocol version Four (IPv4) as a tunnel address, between a first spoke router and a hub router, transmitting a binding information associated with the first spoke router by the hub router to the second spoke router, forwarding an IPv4 data packet from the first spoke router to the second spoke router over the IPv6 multipoint tunnel via the hub router, and establishing a direct communication path between the second spoke router and the first spoke router using the binding information associated with the first spoke router.- See ¶ 0032-¶ 0033, Claim 7, ¶ 0016).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar to include the teachings of Khalid. The motivation to do so is to allow the system to provide a framework for optimized connectivity of an IPv4 Dynamic Multipoint Virtual Private Network over an IPv6 Internet Protocol/Multiprotocol Label Switching cloud (Khalid – ¶ 0001).
Regarding claim 29.
Tamizkar does not explicitly teach
communicating with an IPv4 controller via the IPv4 over IPv6 tunnel, wherein the IPv4 over IPv6 tunnel is a bidirectional IPv4 over IPv6 tunnel of an underlay network; establishing a control connection with the IPv4 controller; and automatically building the overlay tunnel with the bidirectional IPv4 over IPv6 tunnel as a transport.
However, Khalid teaches
communicating with an IPv4 controller via the IPv4 over IPv6 tunnel, wherein the IPv4 over IPv6 tunnel is a bidirectional IPv4 over IPv6 tunnel of an underlay network (¶ 0006 -A method in particular embodiments includes registering a first spoke router with a hub router, forwarding an Internet Protocol version Four (IPv4) data packet from the first spoke router to a second spoke router over an Internet Protocol version Six (IPv6) multipoint tunnel via the hub router, transmitting a binding information associated with the first spoke router from the hub router to the second spoke- ¶ 0013 -Referring again to FIG. 1, in particular embodiments, data packets may be transmitted either between the hub site 120 (Ipv4 controller), and the spokes 130, 140, or between spoke A 130 and spoke B 140, over the IPv6 cloud 110, via the multipoint tunnels 112-115. Each multipoint tunnel in particular embodiments may be defined to include an IPv4 address as the tunnel IP address, andanIPv6 address as the tunnel source IP address. In particular embodiments, the tunnel source IPv6 address may be used as the source IPv6 address of the IPv6 packet transmitted towards the Hub or Spoke site via the IPv6 cloud – ¶ 0022 - To connect to spoke A 130, in particular embodiments, the hub site 120 receives a null packet from spoke A 130 that includes the encrypted registration extension header (310). This extension header 310 may be sent through the IPv6 multipoint tunnel over the IPv6 cloud, and includes the IPv4 tunnel address and IPv6 address of spoke A 130);.
establishing a control connection with the IPv4 controller; and (¶ 0015 - the extension header may encode spoke A's 130 IPv4 tunnel address and spoke A's 130 IPv6 address, which is used for reachability over the IPv6 network – ¶ 0022 - To connect to spoke A 130, in particular embodiments, the hub site 120 receives a null packet from spoke A 130 that includes the encrypted registration extension header (310). This extension header 310 may be sent through the IPv6 multipoint tunnel over the IPv6 cloud includes the IPv4 tunnel address and IPv6 address of spoke A 130. The hub site 120 may decrypt the encapsulated extension headers using the group key, and then respond with an acknowledgment to spoke A 130 through the IPv6 multipoint tunnels, including an extension header, also encrypted with the group key, encoding the IPv6 tunnel source address and the IPv4 tunnel address of the hub site 120 (320). In particular embodiments, the hub site 120 may update the binding table with spoke A 130, to register spoke A 130 with the hub site 120 and establishing a connection);
automatically building the overlay tunnel with the bidirectional IPv4 over IPv6 tunnel as a transport (Abstract - and establishing a direct communication path by the second spoke router with the first spoke route based on the received binding information are provided – ¶ 0006 - establishing a direct communication path by the second spoke router with the first spoke router based on the received binding information – ¶ 0019 - Upon receiving and decrypting the new binding information encoded within the extension header sent from spoke B 140, spoke A 130 will update its own binding information, thus creating a direct connection tunnel
115 between spoke A 130 and spoke B 140 over the IPv6 cloud 110, without needing to send traffic via a hub site 120. In this manner, in particular embodiments, using the IPv6 functionalities, the previously required next hop resolution protocol (NHRP) is no longer needed in DMVPN for the next-hop resolution related to each spoke site network entity, device or router).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar to include the teachings of Khalid. The motivation to do so is to allow the system to provide a framework for optimized connectivity of an IPv4 Dynamic Multipoint Virtual Private Network over an IPv6 Internet Protocol/Multiprotocol Label Switching cloud (Khalid – ¶ 0001).
Regarding claim 35,
Tamizkar teaches one or more computer-readable non-transitory storage media embodying instructions that, when executed by a processor, cause the processor to perform operations comprising:
configuring a loopback interface ( ¶ 0026 - configuring a first loopback interface and assigning an internal Virtual Route Forwarder (VRF) to the first loopback interface; configuring a second loopback interface and assigning an internal Virtual Route Forwarder (VRF2) to the second loopback interface – For the first GRE tunnel, assigning the first loopback interface as a source point of the first GRE tunnel and assigning the second loopback interface as a destination point of the first GRE tunnel – ¶ 0047 - Creating/configuring Loopback 1 107 A and assigning to internal VRF 107 ( or first VRF) and creating or configuring Loopback 2 (or LB2) 108A and assigning to internal VRF2 108 ( or second VRF) in Router R1 101 – R1# - Interface Loopback 1 // create loopback interface);
assigning the loopback interface an IPv4 address ( ¶ 0047 – IP address 20.20.20.1/24 \\ assign IP address to Loopback 1 - ¶ 0048 - The IP addresses of Loopback 107A and Loopback2 108A are in different subnets i.e.: (0049] Subnet-1 20.20.20.0/24 for Loopback (or LBl) having IP address 20.20.20.1/24 (0050] Subnet-2 30.30.30.0/24 for Loopback2 (or LB2) having IP address 30.30.30.1/24 (0051] It must be noted that the IP address or addresses 20.20.20.1/24 and 30.30.30.1 /24 or the subnets 20.20.20.0/ 24 and 30.30.30.0/24 are only examples);.
configuring an overlay tunnel using the loopback interface (¶ 0059 - for the first GRE tunnel (Tunnel) 107B we assign the first loopback interface (Loopback) 107A as a source point of Tunnel and we assign the second loop back interface (Loopback2) 108A as a destination point of Tunnel. ¶ 0060 Similarly, for the second GRE tunnel (Tunnel2) 108B, we assign the second loopback interface (Loopback2 or LB2) 108A as a source point of Tunnel2 and assign the first loopback interface (Loopback) 107A as a destination point ofTunnel2. This is shown in the following configuration: (0061] 4) Define tunnel source and destination in R1 – ¶ 0062 - interface Tunnel Ip VRF forwarding VRF IP address 10.10.10.1/24 tunnel source Loopback tunnel destination 30.30.30.1 interface Tunnel2 IP VRF forwarding VRF2 IP address 10.10.10.2/24 tunnel source Loopback2 tunnel destination 20.20.20.1).
However, Tamizkar does not explicitly teach
wherein each endpoint of the overlay tunnel is uniquely identified by a Transport Location (TLOC) , represented by a combination of an IP address, a color and an encapsulation
configuring an Internet Protocol version 4 (IPv4) over an Internet Protocol version 6 (IPv6) tunnel between the first network element and a second network element and binding the overlay tunnel to the IPv4 over IPv6 tunnel.
Cisco teaches
wherein each endpoint of the overlay tunnel is uniquely identified by a Transport Location (TLOC) , represented by a combination of an IP address, a color and an encapsulation ( Section – TLOC Attributes Used in Policies – At transport location, or TLOC, defines a specific interface in the overlay network. Each TLOC consists of a set of attributes that are exchanged in OMP updates among the Cisco IOS XE Catalyst SD-WAN devices. Each TLOC is uniquely identified by a 3-tuple of IP address, color, and encapsulation – Section -Control Policy – TLOC routes carry overlay network–specific locator properties, including the IP address of the interface that connects to the transport network, a link color, which identifies a traffic flow, and the encapsulation type. (A TLOC, or transport location, is the physical location where a Cisco vEdge device connects to a transport network. It is identified primarily by IP address, link color, and encapsulation, but a number of other properties are associated with a TLOC - See Also Section Centralized Control Policy Configuration Examples.)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar to include the teachings of Cisco. The motivation to do so is to allow the system to use TLOC routes in order to carry properties associated with Transport locations which are physical point at which the devices connect to the WAN or transport network ( Cisco – Section – Route Types).
Khalid teaches
configuring an Internet Protocol version 4 (IPv4) over IPv6 tunnel between the first network element and a second network element and binding the overlay tunnel to the IPv4 over IPv6 tunnel (Fig.1, ¶ 0007 -. FIG. 1 is a block diagram of a Dynamic Multipoint Virtual Private Network (DMVPN) running on IPv4 technology over an IPv6 cloud for practicing one or more embodiments of the present disclosure; ¶ 0013 - Each multipoint tunnel in particular embodiments may be defined to include an IPv4 address as the tunnel IP address, andanIPv6 address as the tunnel source IP address. In particular embodiments, the tunnel source IPv6 address may be used as the source IPv6 address of the IPv6 packet transmitted towards the Hub or Spoke site via the IPv6 cloud. In particular embodiments, the multipoint tunnel may employ generic routing encapsulation (GRE) – ¶ 0005 - establishing an Internet Protocol version Six (IPv6) multipoint
tunnel with an IPv6 address as a tunnel source address and an Internet Protocol version Four (IPv4) as a tunnel address, between a first spoke router and a hub router, transmitting a binding information associated with the first spoke router by the hub router to the second spoke router, forwarding an IPv4 data packet from the first spoke router to the second spoke router over the IPv6 multipoint tunnel via the hub router, and establishing a direct communication path between the second spoke router and the first spoke router using the binding information associated with the first spoke router.- See ¶ 0032-¶ 0033, Claim 7, ¶ 0016).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar to include the teachings of Khalid. The motivation to do so is to allow the system to provide a framework for optimized connectivity of an IPv4 Dynamic Multipoint Virtual Private Network over an IPv6 Internet Protocol/Multiprotocol Label Switching cloud (Khalid – ¶ 0001).
Regarding claim 36.
Tamizkar does not explicitly teach
communicating with an IPv4 controller via the IPv4 over IPv6 tunnel, wherein the IPv4 over IPv6 tunnel is a bidirectional IPv4 over IPv6 tunnel of an underlay network; establishing a control connection with the IPv4 controller; and automatically building the overlay tunnel with the bidirectional IPv4 over IPv6 tunnel as a transport.
However, Khalid teaches
communicating with an IPv4 controller via the IPv4 over IPv6 tunnel, wherein the IPv4 over IPv6 tunnel is a bidirectional IPv4 over IPv6 tunnel of an underlay network (¶ 0006 -A method in particular embodiments includes registering a first spoke router with a hub router, forwarding an Internet Protocol version Four (IPv4) data packet from the first spoke router to a second spoke router over an Internet Protocol version Six (IPv6) multipoint tunnel via the hub router, transmitting a binding information associated with the first spoke router from the hub router to the second spoke- ¶ 0013 -Referring again to FIG. 1, in particular embodiments, data packets may be transmitted either between the hub site 120 (Ipv4 controller), and the spokes 130, 140, or between spoke A 130 and spoke B 140, over the IPv6 cloud 110, via the multipoint tunnels 112-115. Each multipoint tunnel in particular embodiments may be defined to include an IPv4 address as the tunnel IP address, andanIPv6 address as the tunnel source IP address. In particular embodiments, the tunnel source IPv6 address may be used as the source IPv6 address of the IPv6 packet transmitted towards the Hub or Spoke site via the IPv6 cloud – ¶ 0022 - To connect to spoke A 130, in particular embodiments, the hub site 120 receives a null packet from spoke A 130 that includes the encrypted registration extension header (310). This extension header 310 may be sent through the IPv6 multipoint tunnel over the IPv6 cloud, and includes the IPv4 tunnel address and IPv6 address of spoke A 130);
establishing a control connection with the IPv4 controller; and (¶ 0015 - the extension header may encode spoke A's 130 IPv4 tunnel address and spoke A's 130 IPv6 address, which is used for reachability over the IPv6 network – ¶ 0022 - To connect to spoke A 130, in particular embodiments, the hub site 120 receives a null packet from spoke A 130 that includes the encrypted registration extension header (310). This extension header 310 may be sent through the IPv6 multipoint tunnel over the IPv6 cloud includes the IPv4 tunnel address and IPv6 address of spoke A 130. The hub site 120 may decrypt the encapsulated extension headers using the group key, and then respond with an acknowledgment to spoke A 130 through the IPv6 multipoint tunnels, including an extension header, also encrypted with the group key, encoding the IPv6 tunnel source address and the IPv4 tunnel address of the hub site 120 (320). In particular embodiments, the hub site 120 may update the binding table with spoke A 130, to register spoke A 130 with the hub site 120 and establishing a connection);
automatically building the overlay tunnel with the bidirectional IPv4 over IPv6 tunnel as a transport (Abstract - and establishing a direct communication path by the second spoke router with the first spoke route based on the received binding information are provided – ¶ 0006 - establishing a direct communication path by the second spoke router with the first spoke router based on the received binding information – ¶ 0019 - Upon receiving and decrypting the new binding information encoded within the extension header sent from spoke B 140, spoke A 130 will update its own binding information, thus creating a direct connection tunnel
115 between spoke A 130 and spoke B 140 over the IPv6 cloud 110, without needing to send traffic via a hub site 120. In this manner, in particular embodiments, using the IPv6 functionalities, the previously required next hop resolution protocol (NHRP) is no longer needed in DMVPN for the next-hop resolution related to each spoke site network entity, device or router).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar to include the teachings of Khalid. The motivation to do so is to allow the system to provide a framework for optimized connectivity of an IPv4 Dynamic Multipoint Virtual Private Network over an IPv6 Internet Protocol/Multiprotocol Label Switching cloud (Khalid – ¶ 0001).
Claims 23,30,37 are rejected under 35 U.S.C. 103 as being unpatentable over Tamizkar in view of Cisco further in view of Khalid further in view of Hua et al. Publication No. US 2023/0171223 A1 ( Hua hereinafter) further in view of Sun et al. Publication No. CN 101060493 B ( Sun hereinafter)
Regarding claim 23.
Tamizkar in view of Khalid teaches
receiving an IPv4 packet from a host, wherein the IPv4 packet comprises a service-side source IPv4 address and a destination IPv4 address (Khalid - Fig.3 – Step 330 - receiving data packet destined for V4pcB from V4pcA via Spoke A through IPv6 multipoint tunnel – ¶ 0026 - once a connection has been made between spoke A 130 and the hub site 120, spoke A 130 may send a data packet destined for spoke B 140 over the IPv6 cloud 110, via the hub site 120 ( 430). After the hub site 120 forwards the data packet including the extension headers for spoke A 130 to spoke B 140, spoke A 130 awaits an acknowledgement from spoke B 140);
encapsulating the IPv4 packet within an IPv6 packet; and communicating, via the IPv4 over IPv6 tunnel, the IPv4 packet to the second network element (Khalid - ¶ 0032 - The multipoint tunnel may use Generic Routing Encapsulation (GRE) - ¶ 0035 - the method in particular embodiments may include receiving by the hub router, a data packet encapsulating an extension header encoding registration information from the first spoke router, and updating the binding information from the extension header encapsulated within the received data packet – See Also ¶ 0040 – ¶ 0043);
communicating, via the IPv4 over IPv6 tunnel, the IPv4 packet to the second network element (Khalid - ¶ 0043 - receiving an Internet Protocol version Six (IPv6) encapsulated Internet Protocol version Four (IPv4) data packet from a first spoke router, decapsulating the received IPv6 encapsulated IPv4 data packet, determining whether the IPv4 destination is reachable through . forwarding the IPv6 encapsulated IPv4 data packet with the extension header to the second spoke router – Note: Same motivation as in claim 21).
However, Tamizkar in view of Khalid does not explicitly teach
configuring network address translation (NAT) on the loopback interface of the IPv4 over IPv6 tunnel translating, using NAT, the service-side source IPv4 address to a public IPv4 address;
Hua teaches
[..]using the loopback interface of the IPv4 over IPv6 tunnel (Hua – Fig.11, ¶ 0298 - the tunnel endpoint corresponds to a loopback port on the NAT device - ¶ 0129 - the DS-Lite is deploying an IPv4-in-IPv6 tunnel in an IPv6 network to complete IPv4 service transmission. Herein, an IPv6 service is directly transmitted by using the IPv6 network);
translating, using NAT, the service-side source IPv4 address to a public IPv4 address (¶ 0125 – After performing NAT processing, the separate-style CGN device returns, to the BNG system, public network IPv4 traffic obtained after the NAT translation. When the separate style CGN device is used, address translation and user management are, for example, separately performed in the CGN system and the BNG system – ¶ 0127 - The NAT44 (NAT IPv4-IPv4) indicates to translate one IPv4 address to another IPv4 address. For example, a private network IPv4 address is translated into a public network IPv4 address – ¶ 0138 - NAT address translation is performed on the traffic of the user, to translate a private network IP address of the user to a public network IP address).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar in view of Khalid to include the teachings of Hua. The motivation to do so is to allow the system to perform NAT address translation to translate a private network IP address to a public network IP address in order to enhance security.
Tamizkar in view of Khalid and Hua does not explicitly teach configuring NAT on loopback interface
Sun teaches
configuring NAT on loopback interface (Abstract, Page 3 - The major function of using on router R comprises at least: network address translation NAT and loopback interface loopback; Wherein this network address translation is a private network device configuring static address transition. At least configuration on loopback interface and the interface 1: binding strategy route or access control list ACL set into the network address converting attribute of direction; Interface 2 and loopback interface loopback dispose at least: the network address converting attribute that sets out direction. The loopback loop back interface is a virtual interface, is different from real interface, therefore need not use integrated circuit board, and the effect of this interface is that the message of receiving is transmitted to Intranet. Wherein the IP address of loopback interface loopback is 172.40.10.1, and the IP address of interface1 is 192.168.88.200.The private network IP of this private network affair device is 192.168.88.2, and the corresponding public network IP of static address conversion is172.40.10.2, and dynamic network address transition address pool is 172.40.10.10～172.40.10.20 - Step (1), on the equipment (being router R as shown in Figure 1 in the present embodiment) that private network is connected with public network, enable address transition (NAT) and loopback interface (loopback) at least, and be private network affair device configuring static address transition; Loopback interface is a virtual interface, does not need actual hardware, and the function of this loopback interface is that the packet forwarding that will receive post backs the interface that send –See Page 4).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar in view of Khalid and Hua to include the teachings of Sun. The motivation to do so is to allow the system to enable NAT loopback in order to allow internal users to access local services using public IP instead of private IP.
Regarding claim 30.
Tamizkar in view of Khalid teaches
receiving an IPv4 packet from a host, wherein the IPv4 packet comprises a service-side source IPv4 address and a destination IPv4 address (Khalid - Fig.3 – Step 330 - receiving data packet destined for V4pcB from V4pcA via Spoke A through IPv6 multipoint tunnel – ¶ 0026 - once a connection has been made between spoke A 130 and the hub site 120, spoke A 130 may send a data packet destined for spoke B 140 over the IPv6 cloud 110, via the hub site 120 ( 430). After the hub site 120 forwards the data packet including the extension headers for spoke A 130 to spoke B 140, spoke A 130 awaits an acknowledgement from spoke B 140);
encapsulating the IPv4 packet within an IPv6 packet; and communicating, via the IPv4 over IPv6 tunnel, the IPv4 packet to the second network element (Khalid - ¶ 0032 - The multipoint tunnel may use Generic Routing Encapsulation (GRE) - ¶ 0035 - the method in particular embodiments may include receiving by the hub router, a data packet encapsulating an extension header encoding registration information from the first spoke router, and updating the binding information from the extension header encapsulated within the received data packet – See Also ¶ 0040 – ¶ 0043);
communicating, via the IPv4 over IPv6 tunnel, the IPv4 packet to the second network element (Khalid - ¶ 0043 - receiving an Internet Protocol version Six (IPv6) encapsulated Internet Protocol version Four (IPv4) data packet from a first spoke router, decapsulating the received IPv6 encapsulated IPv4 data packet, determining whether the IPv4 destination is reachable through . forwarding the IPv6 encapsulated IPv4 data packet with the extension header to the second spoke router – Note: Same motivation as in claim 28).
However, Tamizkar in view of Khalid does not explicitly teach
configuring network address translation (NAT) on the loopback interface of the IPv4 over IPv6 tunnel, translating, using NAT, the service-side source IPv4 address to a public IPv4 address;
Hua teaches
[..]using the loopback interface of the IPv4 over IPv6 tunnel (Hua – Fig.11, ¶ 0298 - the tunnel endpoint corresponds to a loopback port on the NAT device - ¶ 0129 - the DS-Lite is deploying an IPv4-in-IPv6 tunnel in an IPv6 network to complete IPv4 service transmission. Herein, an IPv6 service is directly transmitted by using the IPv6 network);
translating, using NAT, the service-side source IPv4 address to a public IPv4 address (¶ 0125 – After performing NAT processing, the separate-style CGN device returns, to the BNG system, public network IPv4 traffic obtained after the NAT translation. When the separate style CGN device is used, address translation and user management are, for example, separately performed in the CGN system and the BNG system – ¶ 0127 - The NAT44 (NAT IPv4-IPv4) indicates to translate one IPv4 address to another IPv4 address. For example, a private network IPv4 address is translated into a public network IPv4 address – ¶ 0138 - NAT address translation is performed on the traffic of the user, to translate a private network IP address of the user to a public network IP address).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar in view of Khalid to include the teachings of Hua. The motivation to do so is to allow the system to perform NAT address translation to translate a private network IP address to a public network IP address in order to enhance security.
Tamizkar in view of Khalid and Hua does not explicitly teach configuring NAT on loopback interface
Sun teaches
configuring NAT on loopback interface (Abstract, Page 3 - The major function of using on router R comprises at least: network address translation NAT and loopback interface loopback; Wherein this network address translation is a private network device configuring static address transition. At least configuration on loopback interface and the interface 1: binding strategy route or access control list ACL set into the network address converting attribute of direction; Interface 2 and loopback interface loopback dispose at least: the network address converting attribute that sets out direction. The loopback loop back interface is a virtual interface, is different from real interface, therefore need not use integrated circuit board, and the effect of this interface is that the message of receiving is transmitted to Intranet. Wherein the IP address of loopback interface loopback is 172.40.10.1, and the IP address of interface1 is 192.168.88.200.The private network IP of this private network affair device is 192.168.88.2, and the corresponding public network IP of static address conversion is172.40.10.2, and dynamic network address transition address pool is 172.40.10.10～172.40.10.20 - Step (1), on the equipment (being router R as shown in Figure 1 in the present embodiment) that private network is connected with public network, enable address transition (NAT) and loopback interface (loopback) at least, and be private network affair device configuring static address transition; Loopback interface is a virtual interface, does not need actual hardware, and the function of this loopback interface is that the packet forwarding that will receive post backs the interface that send –See Page 4).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar in view of Khalid and Hua to include the teachings of Sun. The motivation to do so is to allow the system to enable NAT loopback in order to allow internal users to access local services using public IP instead of private IP.
Regarding claim 37.
Tamizkar in view of Khalid teaches
receiving an IPv4 packet from a host, wherein the IPv4 packet comprises a service-side source IPv4 address and a destination IPv4 address (Khalid - Fig.3 – Step 330 - receiving data packet destined for V4pcB from V4pcA via Spoke A through IPv6 multipoint tunnel – ¶ 0026 - once a connection has been made between spoke A 130 and the hub site 120, spoke A 130 may send a data packet destined for spoke B 140 over the IPv6 cloud 110, via the hub site 120 ( 430). After the hub site 120 forwards the data packet including the extension headers for spoke A 130 to spoke B 140, spoke A 130 awaits an acknowledgement from spoke B 140);
encapsulating the IPv4 packet within an IPv6 packet; and communicating, via the IPv4 over IPv6 tunnel, the IPv4 packet to the second network element (Khalid - ¶ 0032 - The multipoint tunnel may use Generic Routing Encapsulation (GRE) - ¶ 0035 - the method in particular embodiments may include receiving by the hub router, a data packet encapsulating an extension header encoding registration information from the first spoke router, and updating the binding information from the extension header encapsulated within the received data packet – See Also ¶ 0040 – ¶ 0043);
communicating, via the IPv4 over IPv6 tunnel, the IPv4 packet to the second network element (Khalid - ¶ 0043 - receiving an Internet Protocol version Six (IPv6) encapsulated Internet Protocol version Four (IPv4) data packet from a first spoke router, decapsulating the received IPv6 encapsulated IPv4 data packet, determining whether the IPv4 destination is reachable through . forwarding the IPv6 encapsulated IPv4 data packet with the extension header to the second spoke router – Note: same motivation as in claim 35).
However, Tamizkar in view of Khalid does not explicitly teach
configuring network address translation (NAT) on the loopback interface of the IPv4 over IPv6 tunnel translating, using NAT, the service-side source IPv4 address to a public IPv4 address;
Hua teaches
[..]using the loopback interface of the IPv4 over IPv6 tunnel (Hua – Fig.11, ¶ 0298 - the tunnel endpoint corresponds to a loopback port on the NAT device - ¶ 0129 - the DS-Lite is deploying an IPv4-in-IPv6 tunnel in an IPv6 network to complete IPv4 service transmission. Herein, an IPv6 service is directly transmitted by using the IPv6 network);
translating, using NAT, the service-side source IPv4 address to a public IPv4 address (¶ 0125 – After performing NAT processing, the separate-style CGN device returns, to the BNG system, public network IPv4 traffic obtained after the NAT translation. When the separate style CGN device is used, address translation and user management are, for example, separately performed in the CGN system and the BNG system – ¶ 0127 - The NAT44 (NAT IPv4-IPv4) indicates to translate one IPv4 address to another IPv4 address. For example, a private network IPv4 address is translated into a public network IPv4 address – ¶ 0138 - NAT address translation is performed on the traffic of the user, to translate a private network IP address of the user to a public network IP address).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar in view of Khalid to include the teachings of Hua. The motivation to do so is to allow the system to perform NAT address translation to translate a private network IP address to a public network IP address in order to enhance security.
Tamizkar in view of Khalid and Hua does not explicitly teach configuring NAT on loopback interface
Sun teaches
configuring NAT on loopback interface (Abstract, Page 3 - The major function of using on router R comprises at least: network address translation NAT and loopback interface loopback; Wherein this network address translation is a private network device configuring static address transition. At least configuration on loopback interface and the interface 1: binding strategy route or access control list ACL set into the network address converting attribute of direction; Interface 2 and loopback interface loopback dispose at least: the network address converting attribute that sets out direction. The loopback loop back interface is a virtual interface, is different from real interface, therefore need not use integrated circuit board, and the effect of this interface is that the message of receiving is transmitted to Intranet. Wherein the IP address of loopback interface loopback is 172.40.10.1, and the IP address of interface1 is 192.168.88.200.The private network IP of this private network affair device is 192.168.88.2, and the corresponding public network IP of static address conversion is172.40.10.2, and dynamic network address transition address pool is 172.40.10.10～172.40.10.20 - Step (1), on the equipment (being router R as shown in Figure 1 in the present embodiment) that private network is connected with public network, enable address transition (NAT) and loopback interface (loopback) at least, and be private network affair device configuring static address transition; Loopback interface is a virtual interface, does not need actual hardware, and the function of this loopback interface is that the packet forwarding that will receive post backs the interface that send –See Page 4).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar in view of Khalid and Hua to include the teachings of Sun. The motivation to do so is to allow the system to enable NAT loopback in order to allow internal users to access local services using public IP instead of private IP.
Claims 24,31,38 are rejected under 35 U.S.C. 103 as being unpatentable over Tamizkar in view of Cisco further in view of Khalid further in view of Cisco et al. IPSLA configuration Guide , Cisco IOS Release 15 M&T (Cisco_IPSLA hereinafter)
Regarding claim 24.
Tamizkar in view Khalid further teaches
acquiring an IPv6 address for a physical interface of the first network element, wherein the physical interface is used to configure the IPv4 over IPv6 tunnel between the first network element and the second network element ( Khalid - ¶ 0015 - the extension header may encode spoke A's 130 IPv4 tunnel address and spoke A's 130 IPv6 address, which is used for reachability over the IPv6 network. The hub site 120, after receiving this extension header may acknowledge the information from Spoke A 130 an respond with another extension header including the hub site's 120 IPv4 tunnel address and the hub site's 120 IPv6 address ; ¶ 0047 -In particular embodiments, the network device 200 includes a network communication interface 210 with one or more communication terminals 211-21n, coupled to one or more processors 240, which will execute a set of instructions 230 encoded onto a memory 220. The program code 230 encoded onto the memory 220 is a set of instructions that when executed by the one or more processors defines the above method of connecting an IPv4 DMVPN over an IPv6 network cloud 110. The network device may be configured for use as a router at spoke A 130);
acquiring an updated IPv6 address for the physical interface of the first network element, [..] operation to notify the second network element of the updated IPv6 address to establish a bidirectional IPv4 over IPv6 tunnel. (Khalid - Fig.4, Receive Binding Update for v4pcB directly from v4pcB or via Hub including Extension Headers for v4pcB IPv4 Tunnel Address and IPv6 Public Address. Stores the IPv6 Address into IPv4 Binding and starts timer for binding. – 450 Send next Data Packet directly to v4pcB via Spoke B using Binding Information received, including IPv6 Public Address of Spoke B. Reset binding counter as binding is used – ¶ 0027 - each spoke is configured to maintain its binding timer and the state for its binding such that the binding may be locally maintained and when a binding lifetime is close to expiration but the binding is in use, a "binding refresh" may be sent out – Note: same motivation as in claim 21).
Tamizkar in view Khalid does not explicitly teach that the operation is Pv6 service level agreement (SLA) hypertext transfer protocol (HTTP) operation
However, Cisco_IPSLA teaches
the operation is an IPV6 service level agreement (SLA) Hypertext Transfer protocol (HTTP) operation (Chapter 16 -shows IPSLAs http operation that can be configured to perform certain tasks such as sending a message to destination device – Note: the claim language does not specify how the network element is using IPV6 SLA HTTP operation. The examiner interpret using the IPV6 SLA HTTP operation as equivalent to using the IPV6 SLA HTTP operation on the source device to send a message to destination using http {get | raw} url [name-server ip-address] [version version-number] [source-ip {ip-address |hostname}] [source-port port-number] [cache {enable | disable}] [proxy proxy-url]).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar in view of Khalid to include the teachings of Cisco_IPSLA. The motivation to do so is to allow the system to provide the message with appropriate information to a destination using HTTP protocol.
Regarding claim 31.
Tamizkar in view Khalid further teaches
acquiring an IPv6 address for a physical interface of the first network element, wherein the physical interface is used to configure the IPv4 over IPv6 tunnel between the first network element and the second network element ( Khalid - ¶ 0015 - the extension header may encode spoke A's 130 IPv4 tunnel address and spoke A's 130 IPv6 address, which is used for reachability over the IPv6 network. The hub site 120, after receiving this extension header may acknowledge the information from Spoke A 130 an respond with another extension header including the hub site's 120 IPv4 tunnel address and the hub site's 120 IPv6 address ; ¶ 0047 -In particular embodiments, the network device 200 includes a network communication interface 210 with one or more communication terminals 211-21n, coupled to one or more processors 240, which will execute a set of instructions 230 encoded onto a memory 220. The program code 230 encoded onto the memory 220 is a set of instructions that when executed by the one or more processors defines the above method of connecting an IPv4 DMVPN over an IPv6 network cloud 110. The network device may be configured for use as a router at spoke A 130);
acquiring an updated IPv6 address for the physical interface of the first network element, [..] operation to notify the second network element of the updated IPv6 address to establish a bidirectional IPv4 over IPv6 tunnel. (Khalid - Fig.4, Receive Binding Update for v4pcB directly from v4pcB or via Hub including Extension Headers for v4pcB IPv4 Tunnel Address and IPv6 Public Address. Stores the IPv6 Address into IPv4 Binding and starts timer for binding. – 450 Send next Data Packet directly to v4pcB via Spoke B using Binding Information received, including IPv6 Public Address of Spoke B. Reset binding counter as binding is used – ¶ 0027 - each spoke is configured to maintain its binding timer and the state for its binding such that the binding may be locally maintained and when a binding lifetime is close to expiration but the binding is in use, a "binding refresh" may be sent out – Note: same motivation as in claim 28).
Tamizkar in view Khalid does not explicitly teach that the operation is Pv6 service level agreement (SLA) hypertext transfer protocol (HTTP) operation
However, Cisco_IPSLA teaches
the operation is an IPV6 service level agreement (SLA) Hypertext Transfer protocol (HTTP) operation (Chapter 16 -shows IPSLAs http operation that can be configured to perform certain tasks such as sending a message to destination device – Note: the claim language does not specify how the network element is using IPV6 SLA HTTP operation. The examiner interpret using the IPV6 SLA HTTP operation as equivalent to using the IPV6 SLA HTTP operation on the source device to send a message to destination using http {get | raw} url [name-server ip-address] [version version-number] [source-ip {ip-address |hostname}] [source-port port-number] [cache {enable | disable}] [proxy proxy-url]).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar in view of Khalid to include the teachings of Cisco_IPSLA. The motivation to do so is to allow the system to provide the message with appropriate information to a destination using HTTP protocol.
Regarding claim 38.
Tamizkar in view Khalid further teaches
acquiring an IPv6 address for a physical interface of the first network element, wherein the physical interface is used to configure the IPv4 over IPv6 tunnel between the first network element and the second network element ( Khalid - ¶ 0015 - the extension header may encode spoke A's 130 IPv4 tunnel address and spoke A's 130 IPv6 address, which is used for reachability over the IPv6 network. The hub site 120, after receiving this extension header may acknowledge the information from Spoke A 130 an respond with another extension header including the hub site's 120 IPv4 tunnel address and the hub site's 120 IPv6 address ; ¶ 0047 -In particular embodiments, the network device 200 includes a network communication interface 210 with one or more communication terminals 211-21n, coupled to one or more processors 240, which will execute a set of instructions 230 encoded onto a memory 220. The program code 230 encoded onto the memory 220 is a set of instructions that when executed by the one or more processors defines the above method of connecting an IPv4 DMVPN over an IPv6 network cloud 110. The network device may be configured for use as a router at spoke A 130);
acquiring an updated IPv6 address for the physical interface of the first network element, [..] operation to notify the second network element of the updated IPv6 address to establish a bidirectional IPv4 over IPv6 tunnel. (Khalid - Fig.4, Receive Binding Update for v4pcB directly from v4pcB or via Hub including Extension Headers for v4pcB IPv4 Tunnel Address and IPv6 Public Address. Stores the IPv6 Address into IPv4 Binding and starts timer for binding. – 450 Send next Data Packet directly to v4pcB via Spoke B using Binding Information received, including IPv6 Public Address of Spoke B. Reset binding counter as binding is used – ¶ 0027 - each spoke is configured to maintain its binding timer and the state for its binding such that the binding may be locally maintained and when a binding lifetime is close to expiration but the binding is in use, a "binding refresh" may be sent out – Note: Same motivation as in claim 35).
Tamizkar in view Khalid does not explicitly teach that the operation is Pv6 service level agreement (SLA) hypertext transfer protocol (HTTP) operation
However, Cisco_IPSLA teaches
the operation is an IPV6 service level agreement (SLA) Hypertext Transfer protocol (HTTP) operation (Chapter 16 -shows IPSLAs http operation that can be configured to perform certain tasks such as sending a message to destination device – Note: the claim language does not specify how the network element is using IPV6 SLA HTTP operation. The examiner interpret using the IPV6 SLA HTTP operation as equivalent to using the IPV6 SLA HTTP operation on the source device to send a message to destination using http {get | raw} url [name-server ip-address] [version version-number] [source-ip {ip-address |hostname}] [source-port port-number] [cache {enable | disable}] [proxy proxy-url]).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar in view of Khalid to include the teachings of Cisco_IPSLA. The motivation to do so is to allow the system to provide the message with appropriate information to a destination using HTTP protocol.
Claims 25,32,39 are rejected under 35 U.S.C. 103 as being unpatentable over Tamizkar in view of Cisco further in view of Khalid further in view of Cisco_IPSLA further in view of Prabhudesai et al. Publication No. US 2023/0164072 A1 ( Prabhudesai hereinafter)
Regarding claim 25.
Tamizkar in view Khalid further teaches wherein the IPv6 address of the physical interface (Khalid - ¶ 0015,¶ 0047 – Note: same motivation as in claim 21). However, Tamizkar in view Khalid does not explicitly teach
IPv6 address of the physical interface is automatically assigned by a Dynamic Host Configuration Protocol version 6 (DHCPv6) server or by an IPv6 auto-configuration.
Prabhudesai teaches
IPv6 address of the physical interface is automatically assigned by a Dynamic Host Configuration Protocol version 6 (DHCPv6) server or by an IPv6 auto-configuration (¶ 0079 - The IDU 508 may also transmit an IANA and an IAPD request to the ODU 504. Such requests may originate from the router WAN interface 511. The ODU 504 may reply from its DHCPv6 server, and the IDU 508 may configure its IPv6 address on the router WAN interface 511 using the IANA response).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar in view of Khalid to include the teachings of Prabhudesai. The motivation to do so is to allow the system to configure its IPv6 address on the router WAN interface that was assigned by the DHCP (Prabhudesai - ¶ 0079).
Regarding claim 32.
Tamizkar in view Khalid further teaches wherein the IPv6 address of the physical interface (Khalid - ¶ 0015,¶ 0047 – Note: the same motivation as in claim 28). However, Tamizkar in view Khalid does not explicitly teach
IPv6 address of the physical interface is automatically assigned by a Dynamic Host Configuration Protocol version 6 (DHCPv6) server or by an IPv6 auto-configuration.
Prabhudesai teaches
IPv6 address of the physical interface is automatically assigned by a Dynamic Host Configuration Protocol version 6 (DHCPv6) server or by an IPv6 auto-configuration (¶ 0079 - The IDU 508 may also transmit an IANA and an IAPD request to the ODU 504. Such requests may originate from the router WAN interface 511. The ODU 504 may reply from its DHCPv6 server, and the IDU 508 may configure its IPv6 address on the router WAN interface 511 using the IANA response).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar in view of Khalid to include the teachings of Prabhudesai. The motivation to do so is to allow the system to configure its IPv6 address on the router WAN interface that was assigned by the DHCP (Prabhudesai - ¶ 0079).
Regarding claim 39.
Tamizkar in view Khalid further teaches wherein the IPv6 address of the physical interface (Khalid - ¶ 0015,¶ 0047 - Note: the same motivation as in claim 35). However, Tamizkar in view Khalid does not explicitly teach
IPv6 address of the physical interface is automatically assigned by a Dynamic Host Configuration Protocol version 6 (DHCPv6) server or by an IPv6 auto-configuration.
Prabhudesai teaches
IPv6 address of the physical interface is automatically assigned by a Dynamic Host Configuration Protocol version 6 (DHCPv6) server or by an IPv6 auto-configuration (¶ 0079 - The IDU 508 may also transmit an IANA and an IAPD request to the ODU 504. Such requests may originate from the router WAN interface 511. The ODU 504 may reply from its DHCPv6 server, and the IDU 508 may configure its IPv6 address on the router WAN interface 511 using the IANA response).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar in view of Khalid to include the teachings of Prabhudesai. The motivation to do so is to allow the system to configure its IPv6 address on the router WAN interface 511 that was assigned by the DHCP (Prabhudesai - ¶ 0079).
Claims 26,33,40 are rejected under 35 U.S.C. 103 as being unpatentable over Tamizkar in view of Cisco further in view of Khalid further in view of Katukam et al. Publication No. US 2022/0210116 A1 ( Katukam hereinafter)
Regarding claim 26.
Tamizkar teaches the IPv4 address of the loopback interface ( ¶ 0026, ¶ 0047). However, Tamizkar does not explicitly teach that the address of the loopback interface is provided by a service provider.
Katukam teaches
address of the loopback interface is provided by a service provider (¶ 0069 - The active DHCP server on the DSs 352-1, 352-2 may return a pre allocated IP address that may be assigned to a loopback interface -See Also ¶ 0071).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar to include the teachings of Katukam. The motivation to do so is to allow the DHCP to allocate IP address for loopback interface for automatic management of IP addresses.
Regarding claim 33.
Tamizkar teaches the IPv4 address of the loopback interface ( ¶ 0026, ¶ 0047). However, Tamizkar does not explicitly teach that the address of the loopback interface is provided by a service provider.
Katukam teaches
address of the loopback interface is provided by a service provider (¶ 0069 - The active DHCP server on the DSs 352-1, 352-2 may return a pre allocated IP address that may be assigned to a loopback interface -See Also ¶ 0071).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar to include the teachings of Katukam. The motivation to do so is to allow the DHCP to allocate IP address for loopback interface for automatic management of IP addresses.
Regarding claim 40.
Tamizkar teaches the IPv4 address of the loopback interface ( ¶ 0026, ¶ 0047). However, Tamizkar does not explicitly teach that the address of the loopback interface is provided by a service provider.
Katukam teaches
address of the loopback interface is provided by a service provider (¶ 0069 - The active DHCP server on the DSs 352-1, 352-2 may return a pre allocated IP address that may be assigned to a loopback interface -See Also ¶ 0071).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar to include the teachings of Katukam. The motivation to do so is to allow the DHCP to allocate IP address for loopback interface for automatic management of IP addresses.
Claims 27,34 are rejected under 35 U.S.C. 103 as being unpatentable over Tamizkar in view of Cisco further in view of Khalid further in view of Hain et al. Publication No. US 2006/0209885 A1 ( Hain hereinafter)
Regarding claim 27.
Tamizkar in view of Khalid teaches
wherein: the first network element is an edge router (Khalid - Abstract - first spoke router with a hub router, forwarding an Internet Protocol version Four (IPv4) data packet from the first spoke router to a second spoke router over an Internet Protocol version Six (IPv6) multipoint tunnel via the hub router- ¶ 0018 -spoke A 130 will update its own binding information, thus creating a direct connection tunnel 115 between spoke A 130 and spoke B 140 over the IPv6 cloud 110 – Note: Spoke A acts as an edge device using the tunnel to connect the private network (DMVPN (Ipv4) ) to the IPv6 cloud – Note: same motivation as in claim 21).
However, Tamizkar in view of Khalid does not explicitly teach that the second network element is an IPv6 border router
Hain teaches
the first network element is an edge router, the second network element is an IPv6 border router (Fig.1 shows edge node 18 and IPv6 border router – ¶ 0015 - FIG. 1 shows two IPv4 networks 10, 12 in communication with an IPv6 network 14. The IPv6 network 14 includes IPv6 nodes 16 which implement IPv6 layer functionality and the IPv4 network includes IPv4 nodes 18. For clarity of depiction, only edge routers are shown in FIG. 1 and interior nodes are omitted. The edge nodes 16 at the ingress and egress of the IPv6 network are in communication with the IPv4 networks 10, 12 and the edge nodes 18 of the IPv4 networks 10 are in communication with the IPv6 network. The edge nodes 16 are referred to herein as IPv4/IPv6 border routers).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar in view of Khalid to include the teachings of Hain. The motivation to do so is to allow the system for automatically interconnecting IPv4 networks across an IPv6 network (Hain – Abstract).
Regarding claim 34.
Tamizkar in view of Khalid teaches
wherein: the first network element is an edge router (Abstract - first spoke router with a hub router, forwarding an Internet Protocol version Four (IPv4) data packet from the first spoke router to a second spoke router over an Internet Protocol version Six (IPv6) multipoint tunnel via the hub router- ¶ 0018 -spoke A 130 will update its own binding information, thus creating a direct connection tunnel 115 between spoke A 130 and spoke B 140 over the IPv6 cloud 110 – Note: Spoke A acts as an edge device using the tunnel to connect the private network (DMVPN (Ipv4) ) to the IPv6 cloud - Note: the same motivation as in claim 28).
However, Tamizkar in view of Khalid does not explicitly teach that the second network element is an IPv6 border router
Hain teaches
the first network element is an edge router, the second network element is an IPv6 border router (Fig.1 shows edge node 18 and IPv6 border router – ¶ 0015 - FIG. 1 shows two IPv4 networks 10, 12 in communication with an IPv6 network 14. The IPv6 network 14 includes IPv6 nodes 16 which implement IPv6 layer functionality and the IPv4 network includes IPv4 nodes 18. For clarity of depiction, only edge routers are shown in FIG. 1 and interior nodes are omitted. The edge nodes 16 at the ingress and egress of the IPv6 network are in communication with the IPv4 networks 10, 12 and the edge nodes 18 of the IPv4 networks 10 are in communication with the IPv6 network. The edge nodes 16 are referred to herein as IPv4/IPv6 border routers.)
It would have been obvious to one of ordinary skill in the art before the effective filling date of the invention to modify the teachings of Tamizkar in view of Khalid to include the teachings of Hain. The motivation to do so is to allow the system for automatically interconnecting IPv4 networks across an IPv6 network (Hain – Abstract).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's amendments.
Sundararajan - US 2021/0112034 Al
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 YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5:30 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.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Oscar A Louie can be reached at (571) 270-1684. 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.
/YOUNES NAJI/Primary Examiner, Art Unit 2445