Detailed Action
1. This Office Action is responsive to the Amendment filed 07/02/2026. Claims 9-15 have been withdrawn (please cancel the withdrawn claims 9-15). Claims 1 and 16 have been amended. Claims 1-8 and 16-20 are pending for examination.
Claim Rejections - 35 USC § 103
2. 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.
3. Claims 1, 3 and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over BANSAL et al. (US 2018/0375762 A1), in view of Reinart et al. (US 2025/0068483 A1), hereinafter “BANSAL” and “Reinart” correspondingly.
4. As to claim 1, BANSAL teaches a cloud compute platform comprising:
platform routing components that route traffic to customer virtual networks from a location external to physical devices that host the customer virtual networks (FIGS. 1-2, [0030] and [0036]: the source machine 110 transmits the encapsulated IPv6 packet from the source machine 110 to the destination machine 104, wherein the source machine 110 and destination machine 104 may each be a VM or a PM), the platform routing components configured to:
receive a data packet having a data packet header identifying a first IPv6 address as a destination for the data packet, the first IPv6 address embedding (i) a first IPv4 address assigned to a virtual machine and (ii) a virtual network (VNet) identifier uniquely identifying a customer VNet within the cloud compute platform (FIGS. 1-2, [0036]: the source machine 110 may generate the IPv6 packets and transmit the IPv6 packets to the destination machine 104. The information may include header information in the IPv6 packet including IPv4 destination addresses and metadata. The metadata may include: a virtual network (VNET) identifier (ID) of a VNET of a customer, a subnetwork (subnet) ID of a portion of the VNET, an IP address of a customer VM, etc.); and
based on extraction of the VNet identifier and the first IPv4 address from the first IPv6 address ([0061]: determining whether one or more of the parameters associated with the request and/or the machine executing the application that generated the request are owned and/or subscribed to by al particular customer and/or are part of a particular VNET and/or subnet), route the data packet to a host node within the cloud compute platform that hosts a first virtual machine (VM) reachable via the first IPv4 address and belonging to the customer VNet identified by the VNet identifier ([0062]: if the requested access is permitted, the de-encapsulated IPv6 packet may be forwarded/routed to another (end) application, an end resource and/or machine of an end resource, based on the IPv4 source and/or destination addresses in the de-encapsulated IPv6 packet).
BANSAL does not explicitly teach “the customer VNet utilizes a private IPv4 address range that overlaps with a private IPv4 address range of at least one other customer VNet”.
In an analogous art, Reinart teaches “the customer VNet utilizes a private IPv4 address range that overlaps with a private IPv4 address range of at least one other customer VNet” ([0050] and [0228]: the control plane creates the customer’s VCN in a customer tenancy and creates a subnet with the VCN (and possibly a backup subnet). The Azure and OCI subnets (one in the customer’s Azure VNET and one in the customer’s OCI VCN) use the same Classless Inter-Domain Routing (CIDR)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the teachings of Reinart, into BANSAL’s to achieve the claimed invention to allow customers set up their own IP schemes without knowing or caring what address space other tenants choose.
5. As to claim 3, BANSAL-Reinart teaches the cloud compute platform of claim 1, wherein the platform routing components include: a software-defined networking (SDN) appliance configured to: receive the data packet as part of an encapsulated data packet, the encapsulated data packet having an outer header and an encapsulated portion that includes the data packet header identifying the first IPv6 address as the destination of the data packet; extract, from the first IPv6 address, the VNet identifier and the first IPv4 address; use the VNet identifier and the first IPv4 address to retrieve, from a stored mapping, an internet protocol (IP) address of a host node of the cloud compute platform that hosts a virtual machine associated with the first IPv4 address; update the outer header of the data packet to include the IP address of the host node as a new destination for the data packet; and transmit the data packet with the new destination in the outer header to the host node (Fig. 8, [0049-0050] and [0059-0062]: the resource management application 44 of the destination machine 104 may subsequently receive the encapsulated IPv6 packet and the de-encapsulator 138 de-encapsulates the received packet to determine whether one or more of the parameters associated with the request and/or the machine executing the application that generated the request are owned and/or subscribed to by al particular customer and/or are part of a particular VNET and/or subnet… If the requested access is permitted, the de-encapsulated IPv6 packet may be forwarded/routed to another (end) application, an end resource and/or machine of an end resource, based on the IPv4 source and/or destination addresses in the de-encapsulated IPv6 packet).
6. As to claims 16-17, claims 16-17 are corresponding tangible computer-readable storage media claims that recite similar limitations as of cloud compute platform claims 1 and 3 and do not contain any additional limitations with respect to novelty and/or inventive steps; therefore, they are rejected under the same rationale.
7. Claims 2, 4-8 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over BANSAL-Reinart, in view of WING et al. (US 2019/0319918 A1), hereinafter “Wing”.
8. As to claim 2, BANSAL-Reinart teaches the cloud compute platform of claim 1, wherein the data packet header further identifies a second IPv6 address as a source for the data packet, providing for an update to packet header information that designates the first IPv6 address as a source and the second IPv6 address as a destination (FIG. 8 and [0050]: the IPv6 packet is shown as 552 in Fig. 8 and includes a header and a payload. The header includes prefix fields, an IPv6 source address field and an IPv6 destination address field), but does not explicitly teach “assign the data packet to a select port identifier on the first VM assigned to the first IPv4 address extracted from the first Ipv6 address; and based on assignment of the select port identifier, define an address translation rule that is conditionally applied to data packets arriving from the first IPv4 address and from the select port identifier”.
In an analogous art, WING discloses “assign the data packet to a select port identifier on the first VM assigned to the first IPv4 address extracted from the first Ipv6 address; and based on assignment of the select port identifier, define an address translation rule that is conditionally applied to data packets arriving from the first IPv4 address and from the select port identifier” (FIG. 3B-3C, 4B-4C, [0050]: A NAT address translation rule may provide instructions to replace, in a header of a detected packet, a destination IP address with an IP address of a client application, and to replace, in the header, a destination port with an identifier of a redirect port implemented in the particular virtual machine. Examples of the NAT translation rules are described with references to FIG. 3B-3C and FIG. 4B-4C; FIG. 3B and [0077]: Rule 360 provides that, in a header of data packet 304A, a destination IP address 306A of “127.31.42.79” is to be replaced with “172.31.42.79”, which corresponds to the IP address of VM1 Windows client. Rule 360 also provides that, in the header of data packet 304A, a destination port identifier 308A of “80” is to be replace with “8090”, which corresponds to the identifier of the redirect port implemented in VM1).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of BANSAL-Reinart and WING to achieve the claimed invention to facilitate redirecting communications exchanged between the client application and server application to be encrypted when exchanged between the corresponding virtual machines (WING, [0009]).
9. As to claim 4, BANSAL-Reinart teaches the cloud compute platform of claim 3, further comprising: a decapsulator configured to generate a modified data packet by decapsulating the encapsulated data packet and; a stateful translator configured to: read the first IPv6 address and a second IPv6 address from a header of the modified data packet; extract the first IPv4 address from the first IPv6 address (Fig. 8, [0049-0050] and [0059-0062]: the resource management application 44 of the destination machine 104 may subsequently receive the encapsulated IPv6 packet and the de-encapsulator 138 de-encapsulates the received packet to determine whether one or more of the parameters associated with the request and/or the machine executing the application that generated the request are owned and/or subscribed to by al particular customer and/or are part of a particular VNET and/or subnet), but does not explicitly teach “select a first port identifier of the first VM to assign to the modified data packet; store a translation rule mapping the first port identifier and the first IPv4 address to a pair of addresses including the first IPv6 address and the second IPv6 address; and create updated header information specifying a packet destination that identifies both the first IPv4 address and the first port identifier; and transmit the modified data packet with the updated header information to the first VM assigned to the first IPv4 address”.
In an analogous art, WING discloses that Security controller 103 may be a software application configured to communicate with virtual machines hosted on hosts 106A-C, and configured to provide NAT address translation rules to the virtual machines. The NAT address translation rules may be configured on security controller 103 by a system administrator or by SDN manager 102A. A NAT address translation rule may provide instructions to replace, in a header of a detected packet, a destination IP address with an IP address of a client application, and to replace, in the header, a destination port with an identifier of a redirect port implemented in the particular virtual machine. Examples of the NAT translation rules are described with references to FIG. 3B-3C and FIG. 4B-4C (FIG. 3B-3C, 4B-4C, [0049-0050]). WING also discloses that [address translation] Rule 360 provides that, in a header of data packet 304A, a destination IP address 306A of “127.31.42.79” is to be replaced with “172.31.42.79”, which corresponds to the IP address of VM1 Windows client. Rule 360 also provides that, in the header of data packet 304A, a destination port identifier 308A of “80” is to be replace with “8090”, which corresponds to the identifier of the redirect port implemented in VM1 (FIG. 3B and [0077]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of BANSAL-Reinart and WING to achieve the claimed invention to facilitate redirecting communications exchanged between the client application and server application to be encrypted when exchanged between the corresponding virtual machines (WING, [0009]).
10. As to claim 5, BANSAL-Reinart-WING teaches the cloud compute platform of claim 4, wherein the stateful translator resides on the host node of the first VM assigned to the first IPv4 address (WING, [0014]: NAT agents 303A and 305B in FIG. 3A and NAT agents 304A and 303B in FIG. 4A).
11. As to claim 6, BANSAL-Reinart-WING teaches the cloud compute platform of claim 4, wherein the header of the modified data packet further identifies a second IPv6 address as a source address and the stateful translator is further configured to: replace the source address with a platform address used to communicate with components of the cloud compute platform (WING, FIG. 4A-C and [0090]: Rule 460 describes that, in a header of data packet 404B, a source IP address of “172.31.42.79” is to be replaced with a loopback IP address 415B of “127.0.0.2” and a destination IP address 406B “127.31.36.107” is to be replaced with a loopback IP address 416B of “127.0.0.1”), wherein packets received at the platform address are subject to evaluation against a set of stored translation rules including the translation rule (WING, FIG. 4A-C and [0093-0094]: Rule 470 describes that, in a header of data packet 410A, a source IP address of “127.31.36.107” is to be replaced with the source IP address of “172.31.42.79” of VM3 Windows server, and a destination IP address “127.31.36.107” is to be replaced with a destination IP address of “127.31.36.107 of VM1 Windows client.”)
12. As to claim 7, BANSAL-Reinart-WING teaches the cloud compute platform of claim 4, wherein the second IPv6 address is assigned to virtual machine associated with a multi-tenant service and the first IPv4 address is a private IP address of a customer that subscribes to the multi-tenant service (BANSAL, FIG. 8, [0049-0051]).
13. As to claim 8, BANSAL-Reinart-WING teaches the cloud compute platform of claim 5, wherein the platform routing components are further configured to: receive a return data packet transmitted by the first VM, the return data packet having a packet header identifying the first IPv4 address and the first port identifier as a source of the return data packet; identify a stored translation rule conditionally applied to traffic originating at the first IPv4 address and the first port identifier, the stored translation rule defining the second IPv6 address as the source of the return data packet and the first IPv6 address as the destination for the return data packet; creating an updated header for the return data packet, the updated header identifying the second IPv6 address as a destination and the first IPv6 address as a source; and transmit the return data packet with the updated header to the second IPv6 address (WING, FIG. 4A-C, [0086-0095]: describing Example Translation of a (Response/Return Data) Packet Sent from a Server Application to a Client Application).
14. As to claims 18-20, claims 18-20 are corresponding tangible computer-readable storage media claims that recite similar limitations as of cloud compute platform claims 4-8 and do not contain any additional limitations with respect to novelty and/or inventive steps; therefore, they are rejected under the same rationale.
Response to Arguments
15. Applicant’s arguments filed 07/02/2026j have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
16. 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.
17. Any inquiry concerning this communication or earlier communications from the examiner should be directed to QUANG N NGUYEN whose telephone number is (571) 272-3886.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, KAMAL B. DIVECHA, can be reached at (571) 272-5863. The fax phone number for the organization is (571) 273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/QUANG N NGUYEN/
Primary Examiner, Art Unit 2453
Prosecution Insights