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
This is a Final Office action in response to communications received December 29, 2025. Claims 1, 2, 8, 9, 15, 16 have been canceled. Claims 3, 5-7, 10-14, 17-20 have been amended. Therefore, claims 3-7, 10-14, 17-20 are pending and addressed below.
Minor Informalities
Claim 4 objected to because of the following informalities: Claim 4 recites “a private DNS service”, which is an acronym. Examiner suggests to spell out “DNS” Appropriate correction is required.
Allowable Subject Matter
Claims 6, 7, 13, 14, 19, 20 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.
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 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.
Claims 3, 10, 17 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Vannarath et al. (US 12363073 B1, file date 03/06/2020).
Claims 3, 10, 17:
With respect to claims 3, 10, 17, Vannarath et al. discloses a computer-implemented method (CIM) / computer program product (CPP) / computer system (CS),
(a controller communicatively coupled to the hub VPC and the spoke VPCs, Figure 2), the CIM/CIP/CS comprising:
a set of one or more computer-readable storage media (The software module(s) may be stored in any type of a suitable non-transitory storage medium, or transitory storage medium, Column 4, lines 29-31); and
program instructions (The software module(s) may include an executable application, an application programming interface (API), a subroutine, a function, a procedure, an applet, a servlet, a routine, source code, a shared library/dynamic load library, or one or more instructions. Column 4, lines 22-29), collectively stored in the set of one or more storage media, for causing a processor set (one or more processor cores, Column 4, lines 18) to perform the following computer operations:
creating virtual private endpoints (VPEs) for service endpoints for virtual private clouds (VPCs) of a cloud network (the system and method each establish one or more cryptographically secure tunnels between VPCs operating within a hub-spoke model, Column 3, lines 10-17) (the controller 204 creates each spoke VPC of the spoke VPCs 112.sub.1-112.sub.i, wherein each spoke VPC includes a spoke gateway 202.sub.1-202.sub.j, Column 7, lines 14-17), wherein the VPCs include hubs and/or spokes (a controller communicatively coupled to the hub VPC and the spoke VPCs , Figure 2);
creating, for the VPCs, buckets having names that include VPC identifiers (IDs) (During creation of the spoke VPC, e.g., spoke VPC 112.sub.1, a range of IP addresses, is specified for and assigned to the spoke VPC 112.sub.1. As one example, the range of IP addresses may be a range of IPV4 addresses in the form of a Classless Inter-Domain Routing (CIDR) block, for example, 10.0.0.0/16, the corresponding gateway, e.g., 202.sub.1, is assigned a specific IP address within the specified IP address range, Column 7, lines 37-44) (The recording may be stored, for example, in the configuration files 214, a database and/or other datastore, Column 7, lines 47-48) (Figure 2, 214);
in response to receiving, from a first of the VPCs, a first query for a first of the service endpoints, causing a name included within the first query to be used for parsing for one of the buckets, wherein the parsing identifies a first of the buckets; causing a VPC ID to be extracted from the first bucket; and using the extracted VPC ID as context for resolving the first query (the secure communication link instruction logic 708 accesses the configuration database 704 (and specifically, the configuration files 214) in order to determine information corresponding to the transit gateway and each spoke gateway in order to populate such information in the messages generated by the secure communication link instruction logic 708 discussed above, Column 14, lines 3-9) (The secure communication link instruction logic 708 is configured to, upon execution by one or more processors, generate and cause transmission of messages to a hub VPC and spoke VPCs, the message transmitted to the hub VPC may be addressed to be received be the transit gateway of the hub VPC and include at least the IP address of the spoke gateway of the first spoke VPC, the message transmitted to the first spoke VPC may be addressed to be received be the spoke gateway and include at least the IP address of the transit gateway of the hub VPC, Column 13, line 44-Column 14, line 2),
wherein the first VPC is a spoke (VPC spoke 202, Figure 2), wherein resolving the first query includes allowing access to a private zone of resource records associated with the extracted VPC ID (a gateway (e.g., the gateway 108 or the gateway 202.sub.1) deployed within a virtual private cloud (e.g., the VPC 106 or the VPC 112.sub.1), Column 12, lines 17-21) (the controller 204 may perform operations of deploying a gateway within the hub VPC and creating a firewall around the hub VPC (and any other virtual machine or virtual instance deployed in cloud computing resources to reduce the potential attack surface of the software environment), Column 7, line 65-Column 8, line 3) (the controller 204 creates each spoke VPC of the spoke VPCs 112.sub.1-112.sub.i, wherein each spoke VPC includes a spoke gateway 202.sub.1-202.sub.j. … e.g., spoke VPC 112.sub.1, a range of IP addresses, is specified for and assigned to the spoke VPC 112.sub.1. As one example, the range of IP addresses may be a range of IPV4 addresses in the form of a Classless Inter-Domain Routing (CIDR) block, for example, 10.0.0.0/16. the corresponding gateway, e.g., 202.sub.1, is assigned a specific IP address within the specified IP address range. The controller 204 maintains a recording of the IP address ranges assigned to each spoke VPC and the IP address assigned to each spoke gateway, Column 7, lines 34-51).
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 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 4-5, 11-12, 18 are rejected under 35 U.S.C. 103 as being unpatentable over Vannarath et al. (US 12363073 B1, file date 03/06/2020) in view of Thunga et al. (US 11252126 B1, patent date 02/15/2022).
Claims 4, 11:
With respect to claims 4, 11, Vannarath et al. discloses the limitations of claims 3, 10, as addressed.
Vannarath et al. does not disclose causing a VPE service to perform an API call to a private DNS service to create internal mapping zones, wherein a first of the internal mapping zones includes the private zone of resource records associated with the extracted VPC ID as claimed.
However, Thunga et al. teaches systems and methods are provided for domain name system (DNS) resolutions in a network environment that includes multiple virtual private clouds (VPCs) attached indirectly to each other via a transit gateway that serves as a hub in a hub and spoke model (Abstract), comprising: causing a VPE service to perform an API call to a private DNS service to create internal mapping zones (an application programming interface (API), a command line interface, a graphical user interface (GUI) and/or other interfaces may be provided that enables administrators of individual VPCs to create a transit gateway, attach specific VPCs to that created transit gateway, and configure various aspects of the transit gateway's operation, Column 4, lines 54-60),
wherein a first of the internal mapping zones includes the private zone of resource records (Information stored in association with the transit gateway 106 may include routing data and optionally DNS data (not illustrated in FIG. 1A) associated with the various attached VPCs and associated gateways, a transit gateway may include an attachment to another transit gateway, which enables sharing or propagating of routing data and DNS data between VPCs that are connected to either transit gateway, Column 4, lines 54-Column 5, line 9) associated with the extracted VPC ID (for attaching a VPC to a transit gateway , The information provided by a user via the interface may include, for example, an identifier of the transit gateway (e.g., a string such as “tgw-017ehd83”), the attachment type (such as whether attaching a VPC or VPN), and the VPC to add (which may include a VPC identifier or name, and one or more subnets of the VPC). Column 12, lines 158-33).
Vannarath et al. and Thunga et al. are analogous art because they are from the same field of endeavor of virtual private cloud in Hub and Spoke Models.
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention Thunga et al. in Vannarath et al. for causing a VPE service to perform an API call to a private DNS service to create internal mapping zones, wherein a first of the internal mapping zones includes the private zone of resource records associated with the extracted VPC ID as claimed for purposes of being an efficient approach to establishing relationships between many different VPCs (e.g., dozens, hundreds, or even thousands, any of which may be desired by a given administrator depending on the circumstances). (see Thunga et al. Column 3, lines 5-32)
Claims 5, 12, 18:
With respect to claims 5, 12, 18, Vannarath et al. discloses the limitations of claims 3, 10, 17, as addressed.
Vannarath et al. disclose a first of the hubs (the system and method each establish one or more cryptographically secure tunnels between VPCs operating within a hub-spoke model, a hub VPC may be communicatively coupled with a plurality of spoke VPCs, Column 3, lines 15-19).
Vannarath et al. does not disclose in response to a determination that a private zone of resource records associated with the extracted VPC ID is not found, using the VPE created for the service endpoint associated with a first of the hubs to resolve the first query as claimed.
However, Thunga et al. teaches Systems and methods are provided for domain name system (DNS) resolutions in a network environment that includes multiple virtual private clouds (VPCs) attached indirectly to each other via a transit gateway that serves as a hub in a hub and spoke model (Abstract), the CIM comprising: in response to a determination that a private zone of resource records associated with the extracted VPC ID is not found, using the VPE created for the service endpoint associated with a first of the hubs to resolve the first query (a resolver within VPC B may resolve the first DNS resolution request, To resolve the request in one embodiment, a DNS tree may have been previously generated at VPC B that takes into account the domain information of each of the other VPCs attached to the given transit gateway (as well as the domain information of any other VPCs that VPC B may be peered with outside of the transit gateway, in some instances), and may resolve the request based on that DNS tree. the resolver at VPC B may first check a DNS tree or other DNS data, until finding a match for the request (otherwise returning a non-existent domain indication if no match is ultimately found). Column 14, lines 18-39).
Vannarath et al. and Thunga et al. are analogous art because they are from the same field of endeavor of virtual private cloud in Hub and Spoke Models.
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention Thunga et al. in Vannarath et al. for in response to a determination that a private zone of resource records associated with the extracted VPC ID is not found, using the VPE created for the service endpoint associated with a first of the hubs to resolve the first query as claimed for purposes of being an efficient approach to establishing relationships between many different VPCs (e.g., dozens, hundreds, or even thousands, any of which may be desired by a given administrator depending on the circumstances). (see Thunga et al. Column 3, lines 5-32)
Response to Remarks/Arguments
Applicant's arguments filed on December 29, 2025 have been fully considered but they are not persuasive. In the remarks, Applicant argues that
Claim 3:
Vannarath Fails To Provide A Teaching Of Resource Records Associated With A VPC ID Extracted From A Query, Much Less Providing Access Thereto Within A Private Zone. Claim 3 recites "using the extracted VPC ID as context for resolving the first query, wherein the first VPC is a spoke, wherein resolving the first query includes allowing access to a private zone of resource records associated with the extracted VPC ID." The cited sections of Vannarath provide no reference to access made to resources records associated with a specific VPC ID extracted from a query, and instead, relatively broadly refer to deployment of a gateway in a virtual private cloud and with emphasis on the deployment being able to "to reduce the potential attack surface of the software environment". See NFOA at 6. Applicant asserts that a gateway deployment and protection offered therefrom does not relate whatsoever to access being made available to specific resource records (ones associated with a specific VPC ID extracted from a query). Vannarath disclosure does not pertain to providing access to resource records in the manner recited in claim 3, and more specifically, Vannarath's controller never is described to allowing access to records of any kind in the process of fulfilling a query.
In response to remark/arguments (1), Examiner respectfully disagrees. Vannarath et al. disclose “to determine information corresponding to the transit gateway and each spoke gateway in order to populate such information in the messages generated by the secure communication link instruction logic 708 discussed above” (Column 14, lines 3-9), “the message transmitted to the hub VPC may be addressed to be received be the transit gateway of the hub VPC and include at least the IP address of the spoke gateway of the first spoke VPC, the message transmitted to the first spoke VPC may be addressed to be received be the spoke gateway and include at least the IP address of the transit gateway of the hub VPC” (Column 13, line 44-Column 14, line 2).
Vannarath et al. discloses “a gateway (e.g., the gateway 108 or the gateway 202.sub.1) deployed within a virtual private cloud (e.g., the VPC 106 or the VPC 112.sub.1)” (Column 12, lines 17-21), “the controller 204 may perform operations of deploying a gateway within the hub VPC and creating a firewall around the hub VPC (and any other virtual machine or virtual instance deployed in cloud computing resources to reduce the potential attack surface of the software environment)” (Column 7, line 65-Column 8, line 3), “the controller 204 creates each spoke VPC of the spoke VPCs 112.sub.1-112.sub.i, wherein each spoke VPC includes a spoke gateway 202.sub.1-202.sub.j. … e.g., spoke VPC 112.sub.1, a range of IP addresses, is specified for and assigned to the spoke VPC 112.sub.1. As one example, the range of IP addresses may be a range of IPV4 addresses in the form of a Classless Inter-Domain Routing (CIDR) block, for example, 10.0.0.0/16. the corresponding gateway, e.g., 202.sub.1, is assigned a specific IP address within the specified IP address range. The controller 204 maintains a recording of the IP address ranges assigned to each spoke VPC and the IP address assigned to each spoke gateway” (Column 7, lines 34-51). Therefore, Examiner maintains that Vannarath et al. discloses "using the extracted VPC ID as context for resolving the first query, wherein the first VPC is a spoke, wherein resolving the first query includes allowing access to a private zone of resource records associated with the extracted VPC ID."
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Helai Salehi whose telephone number is 571-270-7468. The examiner can normally be reached on Monday - Friday from 9 am to 5 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Jeff Pwu, can be reached on 571-272-6798. 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).
/HELAI SALEHI/
Examiner, Art Unit 2433
/JEFFREY C PWU/ Supervisory Patent Examiner, Art Unit 2433
Prosecution Insights