Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), filed on 1/13/2026 in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 1/13/2026 has been entered. Claims 1-8 and 21-25 are pending. Claims 9-14 were previously withdrawn from consideration.
Response to Arguments
2. Applicant's arguments are moot in light of the new ground of rejections set forth below.
Claim Rejections - 35 USC § 103
3. the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-8 and 21-25 are rejected under 35 U.S.C. 103 as being unpatentable over Baker et al (US 2022/0263793) in view of KURUDI MATADA et al. (US 20160254997 A1, hereafter KURUDI).
As to claim 1, Baker discloses a system comprising:
a substrate network hosting a service ([0045] and Figures 7-9; 12; 15 and [0186]-[0190], wherein the service instance such as 712, 812, 912 are services hosted by a substrate network, and wherein ), and wherein the DNS query and DNS response are routed through a physical network Virtualization Device Fleet 1120 before reaching SPF S2C Interface 1132 and after leaving CF S2C Interface 1134, therefore the DNS request is received from the substrate network and the DNS resolution is sent to the substrate network; see [0177], “Whereas the virtualization device fleet 1120 is in the physical network of the cloud infrastructure 1100”; and [0187], “At a physical level, the DNS request 1212 is routed through the virtualization device fleet 1120”), the substrate network being external to a software defined network (SDN) (see citation above, since SDN is an overlay network, which is external to a physical network); and the SDN comprising:
a first private network configured for a customer (Figure 7 and [0153]-[0157], wherein “Customer Private Network 720” is the first private network configured for a customer); and
a second private network (i) configured for the service, (ii) including an endpoint and (ii) including a domain name system (DNS) proxy (Fig. 7, the “Service Provider Private Network 710” together with “S2C Resources 730” in combination is equivalent to a second private network (i) configured for the service; (ii) including an endpoint (see Fig. 7 and [0153]-[0157], wherein the interface(s) on the S2C Resources 730 to receive DNS request and DNS response, such as SPF S2C Interface 1132 and CF S2C Interface 1134 of Fig. 12 in combination is equivalent to an endpoint), and (iii) including a domain name system (DNS) proxy (see Fig. 7, “DNS Proxy 732”; Figure 12, “DNS Proxy 1136”), wherein the “Customer Private Network 720” is the first private network configured for a customer; [0153], “FIG. 7 illustrates an example of a service provider private network 710 connected with a customer private network 720 via a set of S2C resources 730 in support of DNS traffic and unproxied S2 traffic, according to at least one embodiment. The service provider private network 710, the customer private network 720, and the S2C resources 730 are examples of the service provider private network 660, the customer private network 670, and the S2C resources 680, respectively”),
wherein:
the DNS proxy is configured for the customer and is associated with the first private network (Fig. 7, wherein the DNS Proxy 732 communicates with the Customer S2C Interface 724 of the Customer Private Network therefore is configured for the Customer and is associated with the first private network which is the Customer Private Network), and
wherein the endpoint is associated with the service and is configured to receive a DNS resolution request associated with the service and sent from the substrate network, send the DNS resolution request to the DNS proxy, receive a DNS resolution from the DNS proxy, and send the DNS resolution to the service (and the substrate network) (Fig. 7 and [0155]-[0157], e.g., “the service resource 712 may initiate a DNS query that includes the FQDN. The DNS query is received by the service provider S2C interface 714 that, in turn, sends it to the set of S2C resources 730. The set of S2C resources 730 include a DNS proxy. The DNS proxy 732 determines a match between the FQDN with a list of FQDNs redefined by the customer. Based on this match, the DNS proxy 732 sends the DNS query to the customer S2C interface 724 that, in turn, sends it to the customer DNS resolver 726. In response, the customer DNS resolver 726 resolves the DNS query by determining the IP address of the target resource 722, where this IP address corresponds to the FQDN and is usable within the customer private network 720 (e.g., is defined as an address within a range of IP addresses of the customer private network 720). A DNS response that includes the target resource's 722 IP address is sent back to the DNS proxy 732 via the customer S2C interface 724… Next, the DNS proxy updates the DNS response by at least replacing the target resource's 722 IP address with the reserved IP address and sends the updated DNS response to the service resource 712 via the service provider S2C interface”; See Figure 7, the interface(s) on the S2C Resources 730 to receive DNS request and DNS response, such as SPF S2C Interface 1132 and CF S2C Interface 1134 of Fig. 12, in combination, being the endpoint, receives DNS request from the Service Instance 712 (and 912) therefore is associated with the service. See Figure 12 and [0186]-[0190], wherein the DNS query and DNS response are routed through a physical network Virtualization Device Fleet 1120 before reaching SPF S2C Interface 1132 and after leaving CF S2C Interface 1134, therefore the DNS request is received from the substrate network before reaching the virtualization device fleet, and the DNS resolution is sent to the substrate network after the virtualization device fleet, see [0177], “Whereas the virtualization device fleet 1120 is in the physical network of the cloud infrastructure 1100”; and [0187], “At a physical level, the DNS request 1212 is routed through the virtualization device fleet 1120”).
Baker teaches that the service initiating a DNS query and receiving a DNS response, e.g., service instance 712, 812, or 912, is in the service provider private network (see figures 7-9) which is partially implemented on the overlay/SDN/virtual network (see Figure 6, indicating that the cloud and VCN only cover portion of the service provider network; and [0005], “the access may be provided via a set of network resources on a cloud infrastructure that virtualizes at least a portion of each of the two private networks”), however, Baker does not expressly disclose that the service instance belongs to the portions that are not virtualized or a non-SDN service.
KURUDI discloses a concept of serving by a SDN controller/server a DNS request received from a non-SDN service/device hosted on a substrate network external to a SDN network (see [0003], “a SDN network device has a flow entry with an action to forward DNS requests to a SDN controller”; [0025], “The network device then forwards the returned DNS request to a DNS server which is reachable through the rest of the network 310”; [0057], “In the above example the network device 100 is a SDN network device. In other examples the network device may be a non-SDN network device with its own local control plane”).
Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine Baker with KURUDI. The suggestion/motivation of the combination would have been to support hybrid network (KURUDI, [0025]).
As to claim 2, Baker-KURUDI discloses the system of claim 1, wherein the second private network includes a first subnet and a second subnet, wherein the first subnet includes the endpoint, and wherein the second subnet includes the DNS proxy (see citation in rejection to claim 1, such as Baker, Figure 1, wherein 710 is a first subnet, and 730 is a second subnet that includes the DNS proxy).
As to claim 3, Baker-KURUDI discloses the system of claim 1, wherein the endpoint is a first endpoint, and wherein the DNS resolution request indicates a DNS corresponding to a second endpoint of the customer, wherein the first private network or an on-premises network of the customer includes the second endpoint, and wherein the second endpoint is accessible to the non-SDN service via the first endpoint and the DNS proxy (Baker, [0155], “the service resource 712 may initiate a DNS query that includes the FQDN. The DNS query is received by the service provider S2C interface 714 that, in turn, sends it to the set of S2C resources 730. The set of S2C resources 730 include a DNS proxy. The DNS proxy 732 determines a match between the FQDN with a list of FQDNs predefined by the customer. Based on this match, the DNS proxy 732 sends the DNS query to the customer S2C interface 724 that, in turn, sends it to the customer DNS resolver 726.” See also [0186], “The service instance 912 initiates a DNS query 1210 for a particular FQDN that belongs to a DNS of the customer”. Here, the FQDN included in the DNS query indicates a DNS corresponding to a second endpoint of the customer. It is to be noted that this interpretation is consistent with the disclosure in the specification, e.g., [0135]. See KURUDI as cited in rejection to claim 1 for the serving being a non-SDN service).
As to claim 4, Baker-KURUDI discloses the system of claim 1, wherein the DNS proxy is a first DNS proxy (see citation in rejection to claim 1), and wherein the SDN further includes a third private network configured for a different customer (Baker, [0229], “This embodiment can enable isolation of networks that may prevent users or customers from interacting with other users', or other customers', resources”; [0004], “Entities, such as customers and service providers, can configure private networks that are deployed on a cloud infrastructure”; claim 7, “The system of claim 1, wherein the first IP address range overlaps with a third IP address range of a third virtual network configured for another customer, wherein the second resource of the service provider that is configured to also provide the service to the other customer based on an access by the second resource to a third resource of the third virtual network.”), wherein the second private network further includes a second DNS proxy configured for the third private network, and wherein the endpoint supports DNS resolutions associated with third private network for the non-SDN service via the second DNS proxy ([0006], “Additionally or alternatively, the private networks of multiple customers may have overlapping IP address ranges. Further, each private may have its own set of private IP addresses even when no IP address range overlap exists”; [0017], “connectivity between a host machine and an NVD for providing I/O virtualization for supporting multitenancy according to certain embodiments”; [0049], “CSPI may support single-tenancy or multi-tenancy architectures”. Here, since each customer’s private network has its own set of private IP addresses, address translation for each customer’s private network is required, hence the DNS proxy code/process that handles a different customer’s translation by reading in and comparing with the respective customer-defined FQDN list can be considered a different DNS proxy. See KURUDI as cited in rejection to claim 1 for the serving being a non-SDN service).
As to claim 5, Baker-KURUDI discloses the system of claim 4, wherein the first private network and the third private network have overlapping IP addresses, and wherein the non-SDN service of the substrate network is a multi-tenant service (Baker, [0006], “Additionally or alternatively, the private networks of multiple customers may have overlapping IP address ranges. Further, each private may have its own set of private IP addresses even when no IP address range overlap exists”; [0017], “connectivity between a host machine and an NVD for providing I/O virtualization for supporting multitenancy according to certain embodiments”; [0049], “CSPI may support single-tenancy or multi-tenancy architectures”. See KURUDI as cited in rejection to claim 1 for the serving being a non-SDN service).
As to claim 6, Baker-KURUDI discloses the system of claim 1, wherein the endpoint is configured to store a first association between a first reserved IP address associated with the substrate network and an IP address associated with the DNS proxy (Baker, [0188], “The DNS proxy 1136 then updates the DNS request 121 by changing the header information. For example, the source address is changed to the IP address of the customer's S2C interface 1012, where this IP address is configured to receive DNS queries (e.g., “IP2” shown as 10.0.2.22). The destination address is also changed to the IP address of the customer's DNS resolver 1016 (e.g., 10.0.33.33). The payload remains the same and includes the FQDN. The resulting DNS request 1222 is sent to the customer private network 1010. At a logical level, the CF S2C interface 1134 sends the DNS request 1222 to the customer's S2C interface 1012. At a physical level, the DNS request 1222 is routed through the virtualization device fleet 1120”. Since the substrate network is the underlying network wherein DNS requests route through, the IP address of the customer’s S2C interface 1012 is equivalent to a reserved IP address (reserved for receiving DNS queries) associated with the substrate network, and the of the customer’s DNS resolver 1016 is an IP address associated with the DNS proxy based on the DNS proxy’s association with the customers. It is to be noted that the claim does not require a specific type of association),
wherein the DNS resolution request is received based on the first reserved IP address and is sent based on the IP address (It is to be noted that this limitation does not limit what the DNS resolution request is received by or sent by therefore Examiner interprets as any entity. See citation above, wherein the DNS resolution request is received by the customer private network based on the first reserved IP address reserved for receiving DNS queries, and sent to the DNS resolver based on the DNS resolver IP address).
As to claim 7, Baker-KURUDI discloses the system of claim 6, wherein the DNS resolution indicates a second reserved IP address associated with the DNS proxy, wherein the non-SDN service is configured to store a second association between the second reserved IP address and a third reserved IP address associated with the substrate network (Baker, [0155]-[0157], “A DNS response that includes the target resource's 722 IP address is sent back to the DNS proxy 732 via the customer S2C interface 724. Because the target resource's 722 IP address in the DNS response is usable only in the context of the customer private network 720 and not that of the service provider private network 710, the DNS proxy generates and associates a reserved IP address with the target resource's 722 IP address. The reserved IP address can be defined as an address outside the range of the customer private network's 720 IP addresses and outside the range of the service provider private network's 710 IF addresses. The association may be stored in a NAT mapping 734 between the reserved IP address and the target resource's 722 IP address, where this NAT mapping 734 is maintained by the set of S2C resources 730”; [0157], “Next, the DNS proxy updates the DNS response by at least replacing the target resource's 722 IP address with the reserved IP address and sends the updated DNS response to the service resource 712 via the service provider S2C interface. The service resource 712 receives this DNS response and determines that the FQDN is associated with the reserved IP address can cache this association for subsequent use”, wherein the reserved IP address is equivalent to a second reserved IP address. See [0168], “supports DNS resolutions of DNS queries related to a domain of the service provider private network 910 (e.g., to FQDNs having IP addresses within the IP address range of the service provider private network 910” indicating that some FQDNs are also mapped to an IP address of the service provider private network 910, which is equivalent to a third reserved IP address associated with substrate network, see explanation in rejection to claim 1, wherein the DNS queries and responses are routed through physical network therefore all these addresses are associated with the substrate network. It is to be noted that the claim does not require a specific type of association. See KURUDI as cited in rejection to claim 1 for the serving being a non-SDN service).
As to claim 8, Baker-KURUDI discloses the system of claim 7, wherein the endpoint is further configured to receive, from the substrate network based on the third reserved IP address, a request for connecting to a different endpoint of the customer (Baker, Fig. 7; Fig. 12 and [0156], “The association may be stored in a NAT mapping 734 between the reserved IP address and the target resource's 722 IP address”; [0158], “the service resource 712 may send data destined to the reserved IP address. The flow of the data can be proxied via the DNS proxy 732, in which cases address translations are performed by the DNS proxy 732 according to the NAT mapping 734”, wherein the reserved IP address is for the customer-side target resource therefore is a different endpoint of the customer, different from the DNS resolver. See citation and explanation in rejection to claim 1 that the packets are routed through physical network before reaching the endpoint), the different endpoint corresponding to the DNS (see citation above and also in rejection to claim 1, wherein the target resource is part of the DNS, e.g., Figure 7), and send, based on the second reserved IP address, the request to the DNS proxy (see citation above, the reserved IP address is used to route the request to the DNS proxy).
As to claim 21, discloses the system of claim 1, wherein the substrate network is a non-software defined network (see citation in rejection to claim 1, last limitation, Baker, wherein the substrate network is a physical network which is non-software defined network).
As to claim 22 Baker-KURUDI discloses the system of claim 1, wherein the substrate network is a non-overlay network (see citation in rejection to claim 1, last limitation, Baker, wherein the substrate network is a physical network which is non-overlay).
As to claim 23, Baker-KURUDI discloses the system of claim 1, wherein the substrate network is a physical network (see citation in rejection to claim 1, last limitation, Baker, wherein the substrate network is a physical network).
As to claim 24, Baker-KURUDI discloses the system of claim 1, wherein the DNS proxy is configured to provide DNS resolution for endpoints located in an on-premises network of the customer that is communicatively coupled to the first private network (Baker, see citation rejection to claim 1 regarding DNS proxy configured to provide DNS resolution for endpoints located in the customer’s private network (i.e., the first private network”), which functionality can be duplicated with the disclosed “AD” concept, see [0054], “The data centers within a region can be further organized and subdivided into availability domains (ADs). An availability domain may correspond to one or more data centers located within a region. A region can be composed of one or more availability domains. In such a distributed environment, CSPI resources are either region-specific, such as a virtual cloud network (VCN), or availability domain specific, such as a compute instance.”; [0055], “The ADs within the same region may be connected to each other by a low latency, high bandwidth network, which makes it possible to provide high-availability connectivity to other networks (e.g., the Internet, customers' on-premise networks, etc.) and to build replicated systems in multiple ADs for both high-availability and disaster recovery. Cloud services use multiple ADs to ensure high availability”; [0081], “A particular compute instance deployed on VCN 104 can communicate with various different endpoints. These endpoints may include endpoints that are hosted by CSPI 200 and endpoints outside CSPI 200…. A compute instance in a subnet hosted by CSPI 101 may also communicate with endpoints that are not hosted by CSPI 101 (i.e., are outside CSPI 101). These outside endpoints include endpoints in the customer's on-premise network 116”).
As to claim 25, Baker-KURUDI discloses the system of claim 24, wherein, in response to a DNS resolution request for an endpoint in the on-premises network of the customer (see citation rejection to claim 24 above), the DNS proxy is configured to return a masked IP address that is mapped to an IP address of the endpoint in the on-premises network (see citation rejection to claim 1 regarding sending DNS resolution to the substrate network. See Baker, [0156], “the DNS proxy generates and associates a reserved IP address with the target resource's 722 IP address”. It is to be noted that the claimed “masked IP address” is interpreted as a “reserved IP address” in light of the specification, paragraph [0024]), and the endpoint is configured to send the DNS resolution indicating the masked IP address to the substrate network (see citation in rejection to claim 1, wherein the DNS resolution is sent by the endpoint/interfaces to the substrate network).
Double Patenting
7. 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).
8. Claims 1-8 and 21-25 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-20 of US Patent 11777897 (hereafter “the patent’897”) in view of KURUDI MATADA et al. (US 20160254997 A1, hereafter KURUDI).
As to claim 1, the patent’897 discloses the claimed invention substantially, except for the service being a non-SDN service. KURUDI discloses a concept of serving by a SDN controller/server a DNS request received from a non-SDN service/device hosted on a substrate network external to a SDN network (see [0003], “a SDN network device has a flow entry with an action to forward DNS requests to a SDN controller”; [0025], “The network device then forwards the returned DNS request to a DNS server which is reachable through the rest of the network 310”; [0057], “In the above example the network device 100 is a SDN network device. In other examples the network device may be a non-SDN network device with its own local control plane”). Before the effective filing date of the invention, it would have been obvious for an ordinary skilled in the art to combine the patent’897 with KURUDI. The suggestion/motivation of the combination would have been to support hybrid network (KURUDI, [0025]). Claims 2-8 ad 21-25 are similarly rejected over claim 1-20 of the patent’897.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUA FAN whose telephone number is (571)270-5311. The examiner can normally be reached on 9-6.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Umar Cheema can be reached at 571-270-3037. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 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.
/HUA FAN/Primary Examiner, Art Unit 2458