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 .
Claim Objections
Claims 6, 8, 16 and 18 are objected to because claims 6, 8, 16 and 18 recite the term “CIDR address”. This acronyms term is not defined in the claims at least for the first time. Any abbreviation or shortened representations of a term should be spelled out completely upon its first use in each claim branch, for example: HTML (Hypertext Markup Language). Appropriate correction is required.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-4, 6-8, 11-14, 16-18, and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Tracy (US 20220263789 A1).
Regarding claim 1, Tracy teaches a method comprising:
providing a cloud service accessible via a virtual IP address in a virtual cloud network (VCN), wherein the VCN is part of an overlay network; ([0047]: A virtual or overlay network is also referred to as a virtual cloud network (VCN). [0049]: A customer can deploy one or more customer resources, such as compute instances, on a customer VCN. [0053]: An overlay IP address is an overlay address associated with an entity in an overlay network, such as with a compute instance in a customer's virtual cloud network (VCN).)
receiving, at a source network virtualization device (NVD), a first packet destined to the virtual IP address; ([0006]: a network virtualization device (NVD) may receive a first packet whose destination address is a first Internet Protocol (IP) address. The NVD may determine that a plurality of IP addresses is associated with the first IP address, wherein the first IP address is associated with a plurality of compute instances, and the plurality of IP addresses includes IP addresses of a plurality of NVDs associated with the plurality of compute instances. The first IP address may be an overlay IP address (e.g., virtual IP address) and the addresses in the plurality of IP addresses may be physical IP addresses (e.g., substrate IP addresses).)
determining, at the source NVD and based upon a dynamic routing gateway table, the VCN mapped to the virtual IP address; ([0007]: the first NVD may determine that the plurality of IP addresses is associated with the first IP address based upon IP mapping information stored by the first NVD, where the IP mapping information indicates that the first IP address maps to the plurality of IP addresses. In some other embodiments, the first NVD may determine that the plurality of IP addresses is associated with the first IP address based upon information in a forwarding table, where the forwarding table includes information indicating that a plurality of next hop routes is associated with the first IP address, the plurality of next hop routes identifying the plurality of IP addresses. [0088]: if the destination is an endpoint within the customer's on-premise network, then the packet may be forwarded by VCN VR 105 to Dynamic Routing Gateway (DRG) gateway 122 configured for VCN 104. The packet may then be forwarded from the gateway to a next hop to facilitate communication of the packet to it final intended destination. [0129]: a VCN Control Plane is provided that computes all the overlay-to-substrate mappings centrally and publishes them to the NVDs and to the virtual network edge devices such as various gateways such as the DRG, the SGW, the IGW, etc.)
identifying, at the source NVD and based upon the virtual IP address, a substrate IP address of a destination NVD that implements a virtual network interface card (VNIC) associated with the virtual IP address; and ([0047]: An overlay network is a logical (or virtual) network that runs on top of a physical substrate network. [0052]: to learn and store mappings that map overlay addresses in the virtual network to actual physical addresses in the substrate network, and vice versa.)
communicating the first packet from the source NVD to the destination NVD using the substrate IP address. ([0006]: The first packet may then be communicated from the particular NVD to the first compute instance. The first IP address may be an overlay IP address and the addresses in the plurality of IP addresses may be physical IP addresses (e.g., substrate IP addresses).)
Regarding claim 2, Tracy teaches the method of claim 1.
Tracy teaches determining, at the source NVD and based upon the virtual IP address, that the dynamic routing gateway table executed on the source NVD is to be used for routing the first packet, ([0007]: the first NVD may determine that the plurality of IP addresses is associated with the first IP address based upon IP mapping information stored by the first NVD, where the IP mapping information indicates that the first IP address maps to the plurality of IP addresses. In some other embodiments, the first NVD may determine that the plurality of IP addresses is associated with the first IP address based upon information in a forwarding table, where the forwarding table includes information indicating that a plurality of next hop routes is associated with the first IP address, the plurality of next hop routes identifying the plurality of IP addresses. [0088]: if the destination is an endpoint within the customer's on-premise network, then the packet may be forwarded by VCN VR 105 to Dynamic Routing Gateway (DRG) gateway 122 configured for VCN 104. The packet may then be forwarded from the gateway to a next hop to facilitate communication of the packet to it final intended destination. [0129]: a VCN Control Plane is provided that computes all the overlay-to-substrate mappings centrally and publishes them to the NVDs and to the virtual network edge devices such as various gateways such as the DRG, the SGW, the IGW, etc.)
wherein the source NVD executes a network address translation operation and an encapsulation operation with respect to the first packet prior to the first packet being transmitted to the destination NVD. ([0092]: A Network Address Translation (NAT) gateway 128 can be configured for customer's VCN 104 and enables cloud resources in the customer's VCN, which do not have dedicated public overlay IP addresses, access to the Internet and it does so without exposing those resources to direct incoming Internet connections (e.g., L4-L7 connections). This enables a private subnet within a VCN, such as private Subnet-1 in VCN 104, with private access to public endpoints on the Internet. [0047]: Overlay networks typically use encapsulation techniques to differentiate between traffic belonging to different overlay networks. [0052]: Customer traffic is encapsulated to facilitate routing in the virtual network.)
Regarding claim 3, Tracy teaches the method of claim 2.
Tracy teaches wherein the network address translation operation comprises: executing, by the source NVD, an address translation operation that converts a link-local address of the cloud service to the virtual IP address corresponding to the VNIC associated with the cloud service. ([0127]: the NVD may execute one or more virtual functions associated with the overlay network such as executing VNICs associated with compute instances in the VCN, executing a network address translation (NAT) functionality (e.g., the translation of Public IP to Private IP on a host by host basis) and other functions.)
Regarding claim 4, Tracy teaches the method of claim 2.
Tracy teaches wherein the encapsulation operation comprises: encapsulating, by the source NVD, first the packet with an encapsulation header, the encapsulation header comprising information including at least the substrate IP address of the destination NVD. ([0040]: one or more headers of the packet directed to the multi-attached IP address are hashed and the resultant hash value is used to select a particular compute instance from among the multiple compute instances to which to send the packet. [0180]: Tunneling typically involves encapsulating the received packet in one or more headers and the information in the headers is used to communicate the packet from the sending NVD to the receiving NVD via physical network.)
Regarding claim 6, Tracy teaches the method of claim 1.
Tracy teaches wherein the overlay network comprises a plurality of VCNs, each VCN of the plurality of VCNs being assigned a unique CIDR address, and wherein a subset of the plurality of VCNs are permitted to communicate with one or more endpoints in a substrate network. ([0049]: a customer can use resources provided by CSPI to build one or multiple customizable and private virtual network(s) referred to as virtual cloud networks (VCNs). [0065]-[0066]: when a VCN is created, it is associated with a private overlay Classless Inter-Domain Routing (CIDR) address space, which is a range of private overlay IP addresses that are assigned to the VCN (e.g., 10.0/16). A VCN can be subdivided into one or more sub-networks such as one or more subnets. A subnet is thus a unit of configuration or a subdivision that can be created within a VCN. A VCN can have one or multiple subnets. Each subnet within a VCN is associated with a contiguous range of overlay IP addresses (e.g., 10.0.0.0/24 and 10.0.1.0/24) that do not overlap with other subnets in that VCN and which represent an address space subset within the address space of the VCN.)
Regarding claim 7, Tracy teaches the method of claim 1.
Tracy teaches receiving, at the source NVD, a second packet destined to a destination substrate IP address, the destination substrate IP address associated with an endpoint in a substrate network; ([0005]-[0006]: enables packets (e.g., include the first and the second packet) directed to the overlay IP address to be distributed across the multiple compute instances. A network virtualization device (NVD) may receive a first packet (e.g., the second packet) whose destination address is a first Internet Protocol (IP) address. The NVD may determine that a plurality of IP addresses is associated with the first IP address, wherein the first IP address is associated with a plurality of compute instances, and the plurality of IP addresses includes IP addresses of a plurality of NVDs associated with the plurality of compute instances. The first IP address may be an overlay IP address (e.g., virtual IP address) and the addresses in the plurality of IP addresses may be physical IP addresses (e.g., substrate IP addresses).)
determining, at the source NVD and based upon the destination substrate IP address, that the dynamic routing gateway table executed on the source NVD is to be used for routing the second packet; ([0007]: the first NVD may determine that the plurality of IP addresses is associated with the first IP address based upon IP mapping information stored by the first NVD, where the IP mapping information indicates that the first IP address maps to the plurality of IP addresses. In some other embodiments, the first NVD may determine that the plurality of IP addresses is associated with the first IP address based upon information in a forwarding table, where the forwarding table includes information indicating that a plurality of next hop routes is associated with the first IP address, the plurality of next hop routes identifying the plurality of IP addresses. [0088]: if the destination is an endpoint within the customer's on-premise network, then the packet may be forwarded by VCN VR 105 to Dynamic Routing Gateway (DRG) gateway 122 configured for VCN 104. The packet may then be forwarded from the gateway to a next hop to facilitate communication of the packet to it final intended destination. [0129]: a VCN Control Plane is provided that computes all the overlay-to-substrate mappings centrally and publishes them to the NVDs and to the virtual network edge devices such as various gateways such as the DRG, the SGW, the IGW, etc.)
identifying, at the source NVD and based upon the dynamic routing gateway table, a substrate IP address for the substrate network and a tunnel for the destination substrate IP address; and ([0047]: An overlay network is a logical (or virtual) network that runs on top of a physical substrate network. [0052]: to learn and store mappings that map overlay addresses in the virtual network to actual physical addresses in the substrate network, and vice versa. [0189]: a tunneling protocol is used to communicate the packet from the NVD receiving the packet in 804 to the NVD associated with the physical IP address selected in 820.)
communicating the second packet to the endpoint associated with the destination substrate IP address using the substrate IP address for the substrate network and the tunnel. ([0006]: The first packet may then be communicated from the particular NVD to the first compute instance. The first IP address may be an overlay IP address and the addresses in the plurality of IP addresses may be physical IP addresses (e.g., substrate IP addresses). [0180]: Tunneling typically involves encapsulating the received packet in one or more headers and the information in the headers is used to communicate the packet from the sending NVD to the receiving NVD via physical network.)
Regarding claim 8, Tracy teaches the method of claim 1.
Tracy teaches wherein the source NVD advertises a CIDR address of a VCN associated with the source NVD to a top-of-rack (TOR) switch. ([0114]: The NVDs are in turn connected via communication links to top-of-the-rack (TOR) switches, which are connected to physical network (also referred to as the switch fabric). In certain embodiments, the links between a host machine and an NVD, and between an NVD and a TOR switch are Ethernet links. [0155]: FIG. 6A have IP addresses associated with them, where the IP addresses may be physical IP addresses or overlay IP addresses depending upon the component. In the figures, “P_IP” is used to denote a physical IP address and “O_IP” is used to denote an overlay IP address. These IP addresses may be IPv4 addresses (32-bit addresses), IPv6 addresses (128-bit addresses), or other types of IP addresses. In certain embodiments, the IP addresses may be expressed in the Classless Inter-Domain Routing (CIDR) IP address format. [0123]: an NVD may be part of a TOR switch or a TOR switch may be configured to perform functions performed by an NVD that enables the TOR switch to perform various complex packet transformations that are used for a public cloud)
Same rationales apply to claim 11 (CRM) and claim 20 (device) because they are substantially similar to claim 1 (method).
Same rationales apply to claim 12 (CRM) because it is substantially similar to claim 2 (method).
Same rationales apply to claim 13 (CRM) because it is substantially similar to claim 3 (method).
Same rationales apply to claim 14 (CRM) because it is substantially similar to claim 4 (method).
Same rationales apply to claim 16 (CRM) because it is substantially similar to claim 6 (method).
Same rationales apply to claim 17 (CRM) because it is substantially similar to claim 7 (method).
Same rationales apply to claim 18 (CRM) because it is substantially similar to claim 8 (method).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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.
Claim(s) 5 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Tracy (US 20220263789 A1) in view of Tracy-1 (US 20220116323 A1).
Regarding claim 5, Tracy teaches the method of claim 4.
Tracy does not explicitly disclose wherein the destination NVD upon receiving the first packet, removes the encapsulation header from the first packet and forwards the first packet to the VNIC associated with the virtual IP address.
However, Tracy-1 teaches wherein the destination NVD upon receiving the first packet, removes the encapsulation header from the first packet and forwards the first packet to the VNIC associated with the virtual IP address. ([0221]: Upon receiving the response packet, NVD 606 de-capsulates the response packet (i.e., removes the header added to the response packet for tunneling purposes) and forwards the response packet to compute instance 610. FIG. 12C depicts the response packet received by compute instance 610.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Tracy to include above limitations. One would have been motivated to do so because both cited references are belonging to the same inventor, Leonard Thomas Tracy, and same assignee, Oracle International Corp.
Same rationales apply to claim 15 (CRM) because it is substantially similar to claim 5 (method).
Claim(s) 10 is rejected under 35 U.S.C. 103 as being unpatentable over Tracy (US 20220263789 A1) in view of Kumar (US 11323477 B1).
Regarding claim 10, Tracy teaches the method of claim 7.
Tracy does not explicitly disclose wherein the endpoint in the substrate network corresponds to one of an integrated lights out management endpoint, a bastion server, or a network timing server endpoint.
However, Kumar teaches wherein the endpoint in the substrate network corresponds to one of an integrated lights out management endpoint, a bastion server, or a network timing server endpoint. (Abstract: a “bastion” compute instance, including an SSH server and specialized SSH client software, is used to enable connections to instances in a private subnet of a virtual private network. In this context, a bastion instance (or bastion server) is a server designed to be a primary point of access from the internet (e.g., by its inclusion in a public-facing subnet of a virtual private network) and acts as a proxy for one or more compute instances running in a private subnet of a virtual private network.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Tracy to include above limitations. One would have been motivated to do so because a “bastion” compute instance, including an SSH server and specialized SSH client software, is used to enable connections to instances in a private subnet of a virtual private network. In this context, a bastion instance (or bastion server) is a server designed to be a primary point of access from the internet (e.g., by its inclusion in a public-facing subnet of a virtual private network) and acts as a proxy for one or more compute instances running in a private subnet of a virtual private network. As taught by Kumar, Abstract.
Allowable Subject Matter
Claim 9 and 19 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. The following is a statement of reasons for the indication of allowable subject matter: The prior art of record fail to explicitly disclose each and every limitation recited in the combination of claims 1 and 7-9. Same rationales apply to claim 19.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZI YE whose telephone number is (571)270-1039. The examiner can normally be reached Monday - Friday, 8:00am - 4:00pm.
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, Emmanuel Moise can be reached at 5712723865. 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.
/ZI YE/Primary Examiner, Art Unit 2455
Prosecution Insights