DETAILED ACTION
-Claims 1, 8, 13 and 15 are amended.
-Objection to claim 13 is withdrawn based on the claim amendments.
Claims 1-20 are pending.
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 Arguments
Applicant’s Remarks filed on 1/28/2026 have been fully considered.
With respect to the argument that relies on [0002] of Martini, Examiner respectfully notes that [0002] is the background of the Martini prior art and was not relied upon in the office action.
With respect to the argument regard the feature of “hostnames that are un-addressable on a public communications network”, Examiner notes that this feature does not have written description in the specification as presented in the 112(a) rejection below. In addition, the hostname “*.example.com” described in [0010] of Martini does not identify any particular remote endpoint on a public network.
With respect to the argument that Prince does not teach control and management plane functions that are distributed across multiple nodes, this argument is moot because the current office action relies on Martini to teach this feature.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 1-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claims 1 and 8 were amended to recite that “the respective hostnames are un-addressable on a public communications network” and claim 15 was amended to recite “the unique identifier are un-addressable on a public communications network”, however the specification does not provide support for these features. Instead, the specification describes that the “respective hostnames are un-addressable within the decentralized mesh”, see at least [0059,0081], and it describes that the IP address returned to the microservice “does not identify a publicly-addressable computer”, see at least [0061,0087]. Note that both of these features that have support in the specification were previously recited in the claims and have already been rejected and Applicant did not argue those rejections.
The dependent claims inherit this rejection.
Claim Rejections - 35 USC § 103
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Martini (US Pub.No.2016/0315919) in view of Prince et al (US Pub.No.2013/0031356).
Re Claim 1. Martini discloses a system, comprising: at least one processor; and at least one memory that stores executable instructions that, when executed by the at least one processor, facilitate performance of operations, comprising: maintaining a decentralized [service] mesh (i.e. Examples of communication networks include a local area network (“LAN”), a wide area network (“WAN”), peer-to-peer networks) [Martini, para.0059, Note: peer-to-peer networks teach decentralized mesh];
that distributes control and management plane functions across multiple nodes (i.e. the DNS functionality and the monitoring functionality of the network management system 120 may be implemented on separate servers in communication and coordination with one another) [Martini, para.0019]; maintaining, by a connectivity management service of the system, respective associations between respective unique identifiers for respective remote endpoints and respective connectivity information of the respective remote endpoints (i.e. the monitoring rule 164 associated with this domain name indicates the monitoring engine should forward the secure request on to the server associated with the domain name. In response, the monitoring engine 124 may forward the secure request to the website 180 at the appropriate address (e.g., “24.24.24.1”)) [Martini, para.0023, Fig.1 depicts database 160 storing spoofed address associations 162 and monitoring rules associations 164], wherein the respective unique identifiers are unique within the system (i.e. the spoofed addresses are unique such that only one spoofed address may be associated to anyone domain name) [Martini, para.0027, Note: since the spoofed addresses are unique and can only be associated with one domain name, it implies that domain names are also unique), wherein the respective unique identifiers follow a domain name system hostname format (i.e. the database 160 includes spoofed address associations 162. In some implementations, the spoofed address associations 162 arose within a database table mapping domain names to spoofed addresses. In some implementations, the spoofed addresses are unique such that only one spoofed address may be associated to anyone domain name…………….the spoofed address associations 162 arose within a database table mapping domain names to spoofed addresses. In some implementations, the spoofed addresses are unique such that only one spoofed address may be associated to anyone domain name. In some implementations, the spoofed addresses may be an IP address and port combination) [Martini, para.0026-0027], while identifying respective hostnames that are un-addressable within the decentralized [service] mesh; and wherein the respective hostnames are un-addressable on a public communications network that connects the system and the remote endpoints (i.e. the domain name assigned to the SSL certificate may be a wildcard domain such as “*.example.com.”) [Martini, para.10, Note: the domain name format including the * symbol is not addressable within the decentralized mesh and it is not addressable on a public network]; based on receiving, by a connectivity abstraction layer service of the system and from a microservice of the decentralized [service] mesh, a unique identifier of the unique identifiers, returning, to the microservice, an internet protocol address that is unique within the system, wherein the internet protocol address fails to identify a publicly-addressable computer, and storing an association between the unique identifier and the internet protocol address (i.e. The network management system 120 includes a DNS handler 122. In operation, the DNS handler 122 may receive DNS requests from the one or more devices 130a-c connected to the internal network 110. The DNS handler may consult monitoring rules 164 stored in the database 160 (discussed below) to determine whether to return a spoofed address in response to a particular DNS query. For example, the monitoring rules 164 may specify that all traffic to the domain name “www.example.com” should be monitored. In such a configuration, the DNS handler 122 may respond to a DNS request including the domain name “www.example.com” with a spoofed address, such as the address “192.168.0.1” shown associated with the network management system 120 in FIG. 1. In some implementations, the spoofed address may be an IP address associated with the network management system 120. The DNS handler 122 may note this association between the domain name from the DNS query and the returned spoofed address in the database 160 as a spoofed address association 162 (described below)) [Martini, para.0020, Note: a spoofed IP address is only known with the system and therefore does not identify a publicly-addressable computer], (i.e. The one or more devices 130a-c may also include servers. In some implementations, the one or more devices 130a-c include personal devices associated with one or more users. The one or more devices 130a-c may also include devices issued or owned by the entity that provides the internal network 110, such as company-issued smartphones or laptops. In some implementations, the one or more devices 130a-c may include network access or web browsing software (e.g., a web browser) for accessing resources on the Internet 150…………………. a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here) [Martini, para.0018, 0059, Note: this teaches that the client devices of Martini encompass servers or browsers i.e. microservices]; and based on receiving, by the connectivity abstraction layer service and from the microservice, a request to access a remote endpoint of the remote endpoints that is identified by the internet protocol address, identifying the unique identifier from the internet protocol address, determining, from the connectivity management service, connectivity information of the respective connectivity information, based on the unique identifier, and establishing a connection with the remote endpoint using the connectivity information (i.e. The monitoring engine 124 may receive a secure request on “192.168.0.1,” the spoofed address associated with the domain name “www.example.com.” The monitoring engine 124 may determine that the monitoring rule 164 associated with this domain name indicates the monitoring engine should forward the secure request on to the server associated with the domain name. In response, the monitoring engine 124 may forward the secure request to the website 180 at the appropriate address (e.g., “24.24.24.1”)) [Martini, para.0023].
Martini does not explicitly disclose whereas Martini in view of Prince does: maintaining a decentralized service mesh that facilitates execution of microservices within the decentralized service mesh (i.e. system for supporting secure sessions in a cloud-based proxy service in accordance with one embodiment of the invention. The domain owners 135A-L own domains that are hosted on the origin servers 130A-N. The domain owners 135A-L may or may not own or control the origin servers 130A-N. For example, a domain owner 135 may contract with a hosting provider that owns an origin server 130 that hosts at least some of the content of the domain of the domain owner 135. The domains owned by the domain owners 135A-L point to the proxy server 120. That is, a DNS query for any of those domains resolve to the proxy server(s) 120…….……there may be multiple authoritative web servers for the service and they may be geographically distributed …………...multiple proxy servers are geographically distributed in multiple point of presences (POPs). A POP is a collection of networking equipment (e.g., proxy server(s) and may include authoritative name server(s)) that are geographically distributed………… Multiple proxy servers may have the same anycast IP address. The network topology determines the best route to find the nearest server. For example, when a DNS request is made, the network transmits the DNS request to the closest authoritative name server. That authoritative name server then responds with a proxy server within that POP) [Prince, para.0030-32, 0091].
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Martini with Prince because, in Prince, the proxy server 120 can support a secure connection between it and the client device 110 while simultaneously supporting a secure session with the origin server 130 [Prince, para.0114].
Re Claim 2. Martini in view of Prince discloses the system of claim 1, wherein the operations further comprise: acting, by the connectivity abstraction layer service, as a proxy for communications between the microservice and the remote endpoint via the connection (i.e. The network management system may be configured as a gateway between the internal network 110 and the Internet 150, such that traffic directed to the Internet 150 passes through the network management system 120) [Martini, para.0019].
Re Claim 3. Martini in view of Prince discloses the system of claim 1, wherein the receiving of the unique identifier comprises: receiving a domain name system request (i.e. the network management system 120 is operable to receive DNS requests from the one or more devices 130a-c, selectively return spoofed addresses in response to the DNS queries) [Martini, para.0019].
Re Claim 4. Martini in view of Prince discloses the system of claim 3, wherein the returning of the internet protocol address comprises returning a domain name system response (i.e. the DNS handler 122 may respond to a DNS request including the domain name “www.example.com” with a spoofed address) [Martini, para.0020].
Re Claim 5. Martini in view of Prince discloses the system of claim 3, Martini does not explicitly disclose whereas Prince does: wherein the receiving of the unique identifier comprises intercepting the domain name system request, and wherein the domain name system request is directed to a domain name system service that is separate from the connectivity abstraction layer service (i.e. the proxy server receives the request as a result of a DNS (Domain Name System) request for the domain (e.g., example.com) resolving to the proxy server) [Prince, para.0025, Fig.1 shows the DNS and Proxy server are separate entities].
The same motivation to modify with Prince, as in claim 1, applies.
Note that Martini also provides embodiments where the domain name system is separate from the connectivity abstraction layer (i.e. the DNS functionality and the monitoring functionality of the network management system 120 may be implemented on separate servers in communication and coordination with one another) [Martini, para.0019].
Re Claim 6. Martini in view of Prince discloses the system of claim 1, wherein the request to access the remote endpoint comprises a transmission control protocol communication (i.e. the device 130a sends an HTTPS request for “www.example.com” to the spoofed address “192.168.0.1.” In some implementations) [Martini, para.0031, Note: HTTPS relies on TCP].
Re Claim 7. Martini in view of Prince discloses the system of claim 6, wherein the transmission control protocol communication is configured to identify the internet protocol address, and omits a configuration to identify hostnames (i.e. i.e. the device 130a sends an HTTPS request for “www.example.com” to the spoofed address “192.168.0.1.”…………………… A network owner may be able to block access to only certain services operated by a large network entity, as the techniques here and do not rely on the domain name included in an SSL certificate to determine the destination for request) [Martini, para.0031, 0012, Note: HTTPS relies on TCP and TCP relies on IP addresses only not hostnames].
Re Claim 8. In a manner similar to the rejection of claim 1, Martini in view of Prince discloses: a method, comprising: maintaining, by a system comprising at least one processor, respective associations between respective unique identifiers for respective remote endpoints and respective connectivity information of the respective remote endpoints, wherein the respective unique identifiers follow a hostname format that identify respective hostnames that are un-addressable within a decentralized service mesh that distributes control and management plane functions across multiple nodes, and that facilitates execution of microservices within the decentralized service mesh, and wherein the respective hostnames are un-addressable on a public communications network that connects the system and the remote endpoints; based on receiving, by the system and from a microservice of the decentralized service mesh, a unique identifier of the unique identifiers, returning, by the system to the microservice, an internet protocol address that is unique within the system, wherein the internet protocol address does not identify a publicly-addressable computer, and storing, by the system, an association between the unique identifier and the internet protocol address; and based on receiving, by the system and from the microservice, a request to access a remote endpoint of the remote endpoints that is identified by the internet protocol address, identifying, by the system, the unique identifier from the internet protocol address, determining, by the system, connectivity information of the respective connectivity information, based on the unique identifier, and establishing, by the system, a connection with the remote endpoint using the connectivity information.
Re Claim 9. Martini in view of Prince discloses the method of claim 8, Martini does not explicitly disclose whereas Prince does: wherein respective suffixes of the respective unique identifiers identify that the respective unique identifiers identify respective remote endpoints that comprise the remote endpoint (i.e. responsive to a customer registering for secure service for its root domain, the service server 125 automatically requests 172 a digital certificate with two SAN entries for that root domain: one SAN entry for the root domain (e.g., example.com) and one SAN entry for a wildcard covering all subdomains for the root domain (e.g. *.example.com) ) [Prince, para.0054-0055, Note: the root domain is the suffix].
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Martini with Prince because the customer does not have to select each and every FQDN it wants to establish secure session capability for [Prince, para.0114].
Re Claim 10. Martini in view of Prince discloses the method of claim 8, wherein the connectivity information identifies a secure communication mechanism from a group of secure communication mechanisms of the system with which to connect to the remote endpoint (i.e. the proxy server 120 accesses the support secure session data store 124 to determine whether the origin server 130 corresponding to the destination host name has previously supported secure sessions. The support secure session store 124 may also indicate the type of secure session supported by the origin server (e.g., SSL, TLS, versions of SSL or TLS, etc.)) [Prince, para.0113].
The motivation to modify with Prince, as in claim 1, applies.
Re Claim 11. Martini in view of Prince discloses the method of claim 8, further comprising: selecting, by the system, the internet protocol address from any valid internet protocol address, and independent of a subnet (i.e. The spoofed addresses may also be selected from a pool of spoofed addresses. For example, a network administrator may specify that all addresses on the subnet “192.168.*.*” are spoofed addresses, and that the network management system 120 should select an address from this pool when need to spoofed address. In some implementations, specific addresses may be specified as spoofed addresses, and the designations of spoofed addresses may be stored within the database) [Martini, para.0027, Note: in the embodiment where specific addresses are used, the addresses are independent of a subnet].
Re Claim 12. Martini in view of Prince discloses the method of claim 8, Prince further discloses: wherein the connection is made via a transmission control protocol socket (i.e. the proxy server 120 receives a certificate from the origin server 130 (e.g., in an SSL or TLS server-hello message)………. the proxy server 120 completes the secure session negotiation with the origin server 130. For example, the proxy server 120 and the origin server 130 determine the cryptographic protocol used for the encryption, establish session keys for the secure connection, etc. After the secure session negotiation is established) [Prince, para.0116-0117, Note: SSL is secure sockets layer].
The motivation to modify with Prince, as in claim 1, applies.
Re Claim 13. Martini in view of Prince discloses the method of claim 8, Martini in view of Prince further discloses: wherein control and management plane functions of the decentralized service mesh are distributed across a group of nodes of the decentralized service mesh (i.e. system for supporting secure sessions in a cloud-based proxy service in accordance with one embodiment of the invention. The domain owners 135A-L own domains that are hosted on the origin servers 130A-N. The domain owners 135A-L may or may not own or control the origin servers 130A-N. For example, a domain owner 135 may contract with a hosting provider that owns an origin server 130 that hosts at least some of the content of the domain of the domain owner 135. The domains owned by the domain owners 135A-L point to the proxy server 120. That is, a DNS query for any of those domains resolve to the proxy server(s) 120………there may be multiple authoritative web servers for the service and they may be geographically distributed …………...multiple proxy servers are geographically distributed in multiple point of presences) [Prince, para.0030-32, 0091].
The motivation to modify with Prince, as in claim 1, applies.
Re Claim 14. Martini in view of Prince discloses the method of claim 8, Martini in view of Prince further discloses: wherein a secure connectivity mechanism extends the decentralized service mesh to comprise the remote endpoint (i.e. The domains owned by the domain owners 135A-L point to the proxy server 120. That is, a DNS query for any of those domains resolve to the proxy server(s)) [Prince, para.0030].
The motivation to modify with Prince, as in claim 1, applies.
Re Claim 15. In a manner similar to the rejection of claim 1, Martini in view of Prince discloses: a non-transitory computer-readable medium comprising instructions that, in response to execution, cause a system comprising at least one processor to perform operations, comprising: based on receiving, from a microservice of a decentralized service mesh that distributes control and management plane functions across multiple nodes, and that facilitates execution of microservices within the decentralized service mesh, a unique identifier, wherein the unique identifier is un-addressable on a public communications network that connects the microservice and a remote endpoint, returning, to the microservice, an internet protocol address that is unique within the system, wherein the internet protocol address excludes any identification of a publicly-addressable computer, and storing an association between the unique identifier and the internet protocol address; and based on receiving, from the microservice, a request to access the remote endpoint that is identified by the internet protocol address, identifying the internet protocol address from the unique identifier, determining connectivity information based on the unique identifier, and establishing a connection with the remote endpoint using the connectivity information.
Re Claim 16. Martini in view of Prince discloses the non-transitory computer-readable medium of claim 15, Martini in view of Prince further discloses: wherein the unique identifier is a first unique identifier, wherein a first suffix of the first unique identifier identifies that a first associated endpoint is remote, wherein a second suffix of a second unique identifier identifies that a second associated endpoint is local, and wherein the first suffix differs from the second suffix (i.e. a monitoring rule 164 may specify that traffic for the domain name “www.example.com” should be directed to a particular spoofed address pool, that all the traffic directed to the domain name should be decrypted, and traffic including a referrer header of “www.badguy.com” should be blocked) [Martini, para.0028, Note: in this case the first suffix may be badguy.com and the second suffix may be example.com], (i.e. The spoofed address may also be associated with a server separate from the network management system 120, such as a server connected to the internal network 110, or connected to the Internet 150) [Martini, para.0014].
The motivation to modify with Prince, as in claim 1, applies.
Re Claim 17. Martini in view of Prince discloses the non-transitory computer-readable medium of claim 15, wherein the operations further comprise: based on the receiving of the unique identifier, generating the internet protocol address before the returning of the internet protocol address (i.e. The spoofed addresses may also be selected from a pool of spoofed addresses. For example, a network administrator may specify that all addresses on the subnet “192.168.*.*” are spoofed addresses, and that the network management system 120 should select an address from this pool when needed ………………… Upon determining that the domain name “www.sample.com” should be monitored, the network management system 120 interacts with the database to associate the spoofed address “192.168.0.1” with the domain name “www.sample.com” (at 215). In some implementations, the network management system 120 inserts a new row into a table storing the spoofed address associations 162 (shown in FIG. 1). In some implementations, associating the spoofed address may include selecting a free address from a pool of spoofed addresses in the database 160. Associating the spoofed address may also include selecting a specific address configured for the requested domain name from the database…..At 220, the network management system 120 sends a DNS response including the spoofed address “192.168.0.1.”) [Martini, para.0029-0030, Fig.2, Note: selecting from a pool of addresses corresponding to a wildcard format “192.168.*.*” is interpreted as generating].
Re Claim 18. Martini in view of Prince discloses the non-transitory computer-readable medium of claim 15, wherein the association between the unique identifier and the internet protocol address is stored in a first data store, and wherein an association between the unique identifier and the connectivity information is stored in a second data store (i.e. The DNS handler 122 may note this association between the domain name from the DNS query and the returned spoofed address in the database 160 as a spoofed address association 162 ………. the monitoring rule 164 associated with this domain name indicates the monitoring engine should forward the secure request on to the server associated with the domain name. In response, the monitoring engine 124 may forward the secure request to the website 180 at the appropriate address e.g. “24.24.24.1”)) [Martini, para.0020, 0023, Fig.1 depicts database 160 storing spoofed address associations in data store 162 and monitoring rules associations in data store 164].
Re Claim 19. Martini in view of Prince discloses the non-transitory computer-readable medium of claim 15, wherein the receiving of the request to access the remote endpoint comprises: intercepting the request, wherein the request is directed to the remote endpoint as identified by the internet protocol address (i.e. the proxy server receives the request as a result of a DNS (Domain Name System) request for the domain (e.g., example.com) resolving to the proxy server) [Prince, para.0025].
Re Claim 20. Martini in view of Prince discloses the non-transitory computer-readable medium of claim 15, wherein the operations further comprise: acting as a proxy for communications between the microservice and the remote endpoint via the connection (i.e. The network management system may be configured as a gateway between the internal network 110 and the Internet 150, such that traffic directed to the Internet 150 passes through the network management system 120) [Martini, para.0019].
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 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 NOURA ZOUBAIR whose telephone number is (571)270-7285. The examiner can normally be reached Monday - Friday.
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, Kambiz Zand can be reached at 571-272-3811. 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.
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434