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 .
Response to Amendment / Arguments
Regarding the objection to claims for minor informalities:
Applicant’s amendment is considered to have overcome the applied objection. As such, the objection has been withdrawn.
Regarding claims rejected under 35 USC 112(b):
Applicant’s amendment is considered to have overcome the applied rejection. As such, the rejection has been withdrawn.
Regarding claims rejected under 35 USC 103:
Applicant’s amendment is considered to have overcome the applied rejection. As such, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Sharma (US 2017/0171146 A1).
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) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shah (US 2021/0336933 A1) in view of Varda (US 2022/0030049 A1), Maslak (US 2020/0076766 A1), and Sharma (US 2017/0171146 A1).
Regarding claim 1, Shah discloses: A method comprising:
receiving, by a server hosting a domain name service (DNS) configured for an intranet (intranet / private network in Shah), a request from a client that is outside the intranet (user device which is remote over the internet in Shah), the client associated with a tenant of the server (e.g., [0047] and [0058] of Shah concerning users associated with a tenant), to access a web application (application in Shah) hosted in the intranet, the request including a fully qualified domain name (FQDN) of the web application in the intranet;
Refer to at least 752 in FIG. 10 of Shah with respect to an exemplary user request for “intranet.company.com.” For instance, “the user 102 makes a request to the enterprise file share and application… intranet.company.com” in [0097] of Shah.
Refer to at least [0107] of Shah with respect to setting a Domain Name Server (DNS) to provide DNS lookups for the client.
sending, by the server responsive to the FQDN of the web application in the intranet, a notification to an access service, to cause the access service to [establish] a connection to the intranet; and
Refer to at least 756 in FIG. 10, [0085], and [0107] of Shah with respect to utilizing the DNS to determine a destination of the requests; and, for the requests for the enterprise, contacting the topology controller to pre-fetch the topology of the enterprise. The topology controller instructs the redirection proxy to establish an outbound tunnel, and requests are forwarded between the user and the enterprise network.
directing, by the server responsive to the FQDN of the web application in the intranet, the client to send a handshake message to the access service to request access to the web application.
Refer to at least 756-758 in FIG. 10, [0104]-[0105], and [0109] of Shah with respect to forwarding requests through the tunnel, as well as using certificates and tokens for authentication.
Shah discloses pre-fetching a topology for establishing a connection, but does not specifically disclose: the notification to further comprise causing the access service to pre-establish a connection to the intranet. Shah further does not disclose: the request further including an anycast internet protocol (IP) address unique to the server hosting the DNS and associated with the tenant. Shah also discloses a single-tenant (per-customer) broker in [0112], but it does not appear to specify: wherein the DNS is a per-tenant DNS configured to specifically handle requests from the tenant. However, Shah in view of Varda discloses: the notification to further comprise causing the access service to pre-establish a connection to the intranet.
Refer to at least [0017], [0020], [0025], and [0048] of Varda with respect to a DNS lookup as a trigger to preload an on-demand code piece.
The teachings of Shah and Varda concern connecting a remote client to a network, as well as DNS. Accordingly, they are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Shah to further include pre-loading on-demand code pieces for at least the reasons discussed in [0071] of Varda (i.e., performance improvements from faster start times).
Shah-Varda does not specify: the request further including an anycast internet protocol (IP) address unique to the server hosting the DNS and associated with the tenant; wherein the DNS is a per-tenant DNS configured to specifically handle requests from the tenant. However, Shah-Varda in view of Maslak discloses: the request further including an anycast internet protocol (IP) address unique to the server hosting the DNS and associated with the tenant.
Refer to at least [0011], [0074], [0084], [0105] of Maslak with respect to unique pool anycast addresses for DNS server(s) associated with a metro. A DNS request comprises an anycast IP address.
The teachings of Maslak concern DNS architecture and anycast implementation, which are likewise present in Shah-Varda (i.e., [0036] of Varda). As such, these teachings are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Shah-Varda to further implement unique anycast addresses for tenant DNS server groupings for at least the purpose of improved load balancing (e.g., [0005]-[0006] of Maslak).
Shah-Varda-Maslak does not disclose: wherein the DNS is a per-tenant DNS configured to specifically handle requests from the tenant. However, Shah-Varda-Maslak in view of Sharma discloses: wherein the DNS is a per-tenant DNS configured to specifically handle requests from the tenant.
Refer to at least [0038] of Sharma with respect to a known solution of deploying a dedicated DNS machine per tenant.
The teachings of Sharma likewise concern DNS for tenant networks, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Shah-Varda-Maslak to further implement a per-tenant DNS because the substitution of one known element for another would have yielded predictable results to one of ordinary skill in the art at the time (i.e., [0037]-[0040] of Sharma discussing possible solutions for each virtual network having need of a DNS server).
Regarding claim 2, it is rejected for substantially the same reasons as claim 1 above (i.e., the citations and obviousness rationale).
Regarding claim 3, it is rejected for substantially the same reasons as claim 1 above (i.e., the metro and associated DNS server(s) in Maslak).
Regarding claim 4, Shah-Varda-Maslak-Sharma discloses: The method of claim 1, comprising: resolving, by the server, the FQDN to a global FQDN of the access service; and sending, by the server to the client, a message to redirect the client to the access service.
Refer to at least [0082] and [0107]-[0108] of Shah with respect to handling domain names on behalf of clients.
Refer to at least [0085] and [0098] of Shah with respect to redirection.
Regarding claim 5, Shah-Varda-Maslak-Sharma discloses: The method of claim 1, comprising: receiving, by the server from the access service, a message to add or remove the FQDN of the web application.
Refer to at least [0030] of Varda with respect to configuring URLs for which the on-demand code piece is to be run.
This claim would have been obvious for substantially the same reasons as claim 1 above.
Regarding claim 6, it is drawn to repeating the method on different (“another”) components, and is therefore rejected for substantially the same reasons.
Regarding claim 7, Shah-Varda-Maslak-Sharma discloses: The method of claim 1, comprising: causing the access service to pre-establish the connection to the intranet using a connector having a connection to an application server hosting the web application.
Refer to at least he abstract, [0008], and [0041] of Shah with respect to connectors.
Regarding claim 8, Shah-Varda-Maslak-Sharma discloses: The method of claim 1, comprising: causing the access service to request or receive a client certificate from the client, the client certificate including information associated with the intranet; and causing the access service to identify the pre-established connection using the information associated with the intranet and an indication of the FQDN in the handshake message.
Refer to at least [0097]-[0097] and [0104]-[0105] of Shah with respect to client certificates.
Refer to at least [0023] and [0043]-[0044] of Varda with respect to identifying on-demand code pieces based on a hostname and the hostname in a handshake message.
This claim would have been obvious for substantially the same reasons as claim 1 above.
Regarding claim 9, it is rejected for substantially the same reasons as claims 1 and 8 above (i.e., citations to the token / certificate).
Regarding independent claim 10, it is substantially similar to independent claim 1 above, and is therefore likewise rejected (i.e., the citations and obviousness rationale).
Regarding claims 11 and 13-18, they are substantially similar to claims 2-9 above, and are therefore likewise rejected.
Regarding claim 12, it is substantially similar to claim 3 above, and is therefore likewise rejected.
Regarding independent claim 19, it is substantially similar to independent claim 1 above, and is therefore likewise rejected (i.e., the citations and obviousness rationale).
Regarding claim 20, it is substantially similar to claim 4 above, and is therefore likewise rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure (e.g., [0023] and [0049] of WO 2020/087002 A1).
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 VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/Examiner, Art Unit 2432