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 .
Status of Claims
This office action is in response to claims filed on 11/24/2025
Claims 1-20 are pending and rejected; Claims 1, 11 and 20 are independent claims
Response to Arguments
Applicant's arguments filed on 11/24/2025 have been fully considered but they are not persuasive.
With respect to applicant’s argument: the art of record fails to disclose: “wherein the endpoint device is configured to establish network connections on only the predetermined network port” and “thereby establishing an authenticated network connection only on the predetermined network port”
Examiner respectfully disagree with applicant’s argument for the following reasons: Parasseeri disclose the recited claim limitation, (see Parasseeri ¶37, all secure transfers are done using port 443, the standard port for HTTPS traffic [i.e. establishing network connection on only the predetermined network port] ¶38, the present disclosure describes a client that can be paired with a server and receiver using network transport security (TLS). The TLS can be negotiated over port 80 or port 443. Either port 80 or port 443 can be used in combination with a TLS reverse proxy for the handshake; ¶39, client us configured with a browser is implemented for the browsers to act on the initial assumption that port 443 will be used first for an attempted connection, then the port 80 will be tried [i.e. only Port 443 and 80 are used and both are predetermined network ports to establish network connections]) and (see Parasseeri ¶¶36-39, the present disclosure describes a client that can be paired with a server and receiver using network transport security (TLS). The TLS can be negotiated over port 80 or port 443 [i.e. establishing TLS network connection is authenticated network connection only] ). In addition, applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
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.
Claim(s) 1, 5-8, 11 and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Parasseeri US Pub. No.: 2022/0191254 A1 (hereinafter Parasseeri) in view of Roy et al. US Pub.: 2023/0336530 A1 (hereinafter Roy)
Parasseeri discloses:
As to claim 1, an edge compute network (see Parasseeri Fig. 1), comprising:
an endpoint device including a network interface having a plurality of network port (see Parasseeri, Fig. 1 and ¶48, client device 102 makes a first connection and connects to the relay reverse proxy service (connection D) on port 443. The messages are sent to the relay manager 122 on port 443. The receiver uses ports in the range of 5000-5999 to connect to the relay instance 128 [i.e. endpoint device/client device including network interface/110 having a plurality network ports/ ports 443, and 500-599 ) and configured to provide a first outbound request on a predetermined network port (see Parasseeri Fig. 1 and ¶48, ¶48, client device 102 makes a first connection and connects to the relay reverse proxy service (connection D) on port 443) , wherein each network port is configured to not respond to unsolicited incoming traffic (First, see applicant’s own disclosure ¶16, Connectivity between ECE 110 and EO 130 is directed in that the ECE is configured to initiate the connectivity with the EO via the dedicated port (port 443), but to not respond to unsolicited incoming traffic, [i.e. the recited endpoint device is the Edge Compute Endpoint (ECE)]). (see Parasseeri Figs. 1-3 and ¶¶2138 48 65 71-72, the client 102 attempts to connect via the network no to the receiver 124 on a non-standard port (non-443 port) other than via connections B and D. Therefore, because of the blocking over the non-standard (non-443) port by a VPN/firewall the request is denied. The relay backend server 116 service uses a port in the range of 5000-5750 to connect to the receiver 124 [i.e. unsolicited incoming traffic on ports 5000-5999 blocked]) , and wherein the endpoint device is configured to establish network connections on only the predetermined network port (see Parasseeri ¶37, all secure transfers are done using port 443, the standard port for HTTPS traffic [i.e. establishing network connection on only the predetermined network port] ¶38, the present disclosure describes a client that can be paired with a server and receiver using network transport security (TLS). The TLS can be negotiated over port 80 or port 443. Either port 80 or port 443 can be used in combination with a TLS reverse proxy for the handshake; ¶39, client us configured with a browser is implemented for the browsers to act on the initial assumption that port 443 will be used first for an attempted connection, then the port 80 will be tried [i.e. only Port 443 and 80 are used and both are predetermined network ports to establish network connections]); and
an information handling system including a first reverse proxy and a second reverse proxy (see Parasseeri Figs. 1-3 and ¶¶38 72, Client 102 connects to relay reverse Proxy service (NodeJS) [i.e. first reverse proxy]…the relay reverse proxy service 132 connects to a Relay Instance 128 [i.e. second reverse proxy]) , and configured to instantiate an endpoint orchestrator, the first reverse proxy configured to receive the first outbound request on the predetermined network port and to provide the first outbound request to the second reverse proxy, the second reverse proxy configured to provide the first outbound request to the endpoint orchestrator (see Parasseeri Figs. 1-3 , ¶¶64 77, establishing the two connections of a connection between the client 102 and relay reverse proxy (D)[i.e., first reverse proxy], and another connection between the receiver 124 and relay reverse proxy 132 using the relay instance 128 (function 314)[i.e. second reverse proxy]),
thereby establishing an authenticated network connection only on the predetermined network port (see Parasseeri ¶¶36-39, the present disclosure describes a client that can be paired with a server and receiver using network transport security (TLS). The TLS can be negotiated over port 80 or port 443 [i.e. establishing TLS network connection is authenticated network connection only] ) and
Parasseeri does not explicitly disclose but the analogues are Roy discloses:
the endpoint orchestrator configured to authenticate the endpoint device based upon the first outbound request and provide authentication information to the endpoint device to authenticate the information handling system to the endpoint device (see Roy ¶25, two-way authentication (or “mutual authentication”), as used herein, refers to a process in which a client device validates a server certificate of a service or back-end device, and the service or back-end device validates a client certificate of the client device);
wherein the endpoint device is further configured to authenticate the information handling system based upon the authentication information (see Roy ¶25, two-way authentication (or “mutual authentication”), as used herein, refers to a process in which a client device validates a server certificate of a service or back-end device, and the service or back-end device validates a client certificate of the client device), and to open the predetermined network port to the information handling system in response to authenticating the information handling system (see Roy ¶45, service(s) 106 determines the client certificate is acceptable, proxy 108 connects the client device(s) 102 to service(s) 106 using the connection information).
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the invention, to modify the proxy relay implementation for client server connections over wide area network disclosed by Parasseeri to include authentication of endpoint system before opening/connecting the predetermined network port, as thought by Roy. A person with ordinary skill in the art would have been motivated to authenticate the communication devices when connecting to any service that requires mutual or two-way transport layer security (TLS) and enhance security.
As to claim 5, the combination of Parasseeri and Roy discloses the edge computing network of claim 1, wherein the first outbound request includes a first authentication certificate associated with an authentication authority (see Roy, ¶20, server certificate is issued by a trusted certificate authority (e.g., an entity that issues digital certificates) and comprises a list of domain names, hostnames, and IP addresses secured by the server certificate).
Similar rationales applied as above to combine the cited prior art references.
As to claim 6, the combination of Parasseeri and Roy discloses the edge computing network of claim 5, wherein, in authenticating the endpoint device, the endpoint orchestrator is further configured to validate the first authentication certificate (see Roy ¶¶4 25, client device is connected to the service based on the service connection information, validation of the TLS server certificate, and validation of the TLS client certificate).
Same rational as above is applied to combine the cited prior art references.
As to claim 7, the combination of Parasseeri and Roy discloses the edge computing network of claim 6, wherein the authentication information includes a second authentication certificate associated with the authentication authority (see Roy ¶48, validating authentication certificate was issued by a trusted certificate authority).
Similar rationales applied as above to combine the cited prior art references.
As to claim 8, the combination of Parasseeri and Roy discloses the edge computing network of claim 7, wherein, in authenticating the information handling system, the endpoint device is further configured to validate the second authentication certificate (see Roy ¶48, validating authentication certificate was issued by a trusted certificate authority).
Similar rationales applied as above to combine the cited prior art references.
Parasseeri discloses:
As to claim 11, a method, comprising:
Provide on an endpoint device, a network interface having a plurality of network ports (see Parasseeri, Fig. 1 and ¶48, client device 102 makes a first connection and connects to the relay reverse proxy service (connection D) on port 443. The messages are sent to the relay manager 122 on port 443. The receiver uses ports in the range of 5000-5999 to connect to the relay instance 128 [i.e. endpoint device/client device including network interface/110 having a plurality network ports/ ports 443, and 500-599 ), each network port being configured to not respond to unsolicited incoming traffic (see Parasseeri Figs. 1-3 and ¶¶2138 48 65 71-72, connections may be established using TCP, UDP, or any other protocols, in various embodiments, the connections are originated by client 102 and web server 104 using TCP protocols to aid in traversing any firewalls 113 that may be intervening, [i.e. in both UDP and TCP communication the client initiates communication by sending a request/datagram to the servers IP address and port, hence does not respond for unsolicited incoming traffic and TLS reverse proxy handshake is based on TCP protocol inherently preventing unsolicited inbound data exchange]), wherein the endpoint device is configured to establish network connections on only the predetermined network port (First, see applicant’s own disclosure ¶16, Connectivity between ECE 110 and EO 130 is directed in that the ECE is configured to initiate the connectivity with the EO via the dedicated port (port 443), but to not respond to unsolicited incoming traffic, [i.e. the recited endpoint device is the Edge Compute Endpoint (ECE)]). (see Parasseeri Figs. 1-3 and ¶¶2138 48 65 71-72, the client 102 attempts to connect via the network no to the receiver 124 on a non-standard port (non-443 port) other than via connections B and D. Therefore, because of the blocking over the non-standard (non-443) port by a VPN/firewall the request is denied. The relay backend server 116 service uses a port in the range of 5000-5750 to connect to the receiver 124 [i.e. unsolicited incoming traffic on ports 5000-5999 blocked]);
providing, on an information handling system, a first reverse proxy and a second reverse proxy (see Figs. 1-3 and ¶¶38 72, Client 102 connects to relay reverse Proxy service (NodeJS) [i.e. first reverse proxy]…the relay reverse proxy service 132 connects to a Relay Instance 128 [i.e. second reverse proxy]);
instantiating, on the information handling system, an endpoint orchestrator (see Parasseeri ¶58, relay backend server 116 [i.e. an endpoint orchestrator] instantiated/initiated);
sending, by the endpoint device, a first outbound request on a predetermined network port (see Parasseeri Fig. 2 and ¶72, the user's request at the portal attempts a connection to receiver 124 using the relay reverse proxy service (Step 2));
receiving, by the first reverse proxy, the first outbound request on the predetermined network port (see Parasseeri Fig. 2 and ¶72, the user's request at the portal attempts a connection to receiver 124 using the relay reverse proxy service (Step 2));
providing the first outbound request to the second reverse proxy (see Parasseeri Figs. 1-2 and ¶¶48 67 77, reverse proxy act as a “gate” to route traffic from port 443 to the requested service to the relay instance 128 [i.e. the second reverse proxy];
providing, by the second reverse proxy, the first outbound request to the endpoint orchestrator (see Parasseeri ¶66, relay backend server 116 [i.e. endpoint orchestrator] suitably places an outgoing request to the relay reverse proxy 132 that can be forwarded by relay instance 128 [i.e. the second reverse proxy] to the receiver 124);
thereby establishing an authenticated network connection only on the predetermined network port (see Parasseeri ¶¶36-39, the present disclosure describes a client that can be paired with a server and receiver using network transport security (TLS). The TLS can be negotiated over port 80 or port 443 [i.e. establishing TLS network connection is authenticated network connection only] )
Parasseeri does not explicitly disclose but the analogues are Roy discloses:
authenticating the endpoint device based upon the first outbound request (see Roy ¶22, connection settings of a connection scheme indicate a TLS type client certificate, as used herein, is a digital certificate used to confirm the identify or authenticity of a user/client device);
providing authentication information to the endpoint device to authenticate the information handling system to the endpoint device (see Roy ¶25, the connection settings of a connection scheme indicate a TLS type of “one-way” authentication or “two-way” authentication. One-way authentication (or “server-only authentication”), as used herein, refers to a process in which a client device validates a server certificate of a service or back-end device)
authenticating the information handling system based upon the authentication information (see Roy ¶25, a process in which a client device validates a server certificate of a service or back-end device) ; and
opening the predetermined network port to the information handling system in response to authenticating the information handling system (see Roy ¶45, service(s) 106 determines the client certificate is acceptable, proxy 108 connects the client device(s) 102 to service(s) 106 using the connection information).
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the invention, to modify the proxy relay implementation for client server connections over wide area network disclosed by Parasseeri to include authentication of endpoint system before opening/connecting the predetermined network port, as thought by Roy. A person with ordinary skill in the art would have been motivated to authenticate the communication devices when connecting to any service that requires mutual or two-way transport layer security (TLS) and enhance security.
As to claim 15, the combination of Parasseeri and Roy discloses the method of claim 11, wherein the first outbound request includes a first authentication certificate associated with an authentication authority (see Roy, ¶20, server certificate is issued by a trusted certificate authority (e.g., an entity that issues digital certificates) and comprises a list of domain names, hostnames, and IP addresses secured by the server certificate).
Similar rationales applied as above to combine the cited prior art references.
As to claim 16, the combination of Parasseeri and Roy discloses the method of claim 15, wherein, in authenticating the endpoint device, the method further comprises validating the first authentication certificate (see Roy ¶¶4 25, client device is connected to the service based on the service connection information, validation of the TLS server certificate, and validation of the TLS client certificate).
Similar rationales applied as above to combine the cited prior art references.
As to claim 17, the combination of Parasseeri and Roy discloses the method of claim 16, wherein the authentication information includes a second authentication certificate associated with the authentication authority see Roy ¶48, validating authentication certificate was issued by a trusted certificate authority).
Similar rationales applied as above to combine the cited prior art references.
As to claim 18, the combination of Parasseeri and Roy discloses the method of claim 17, wherein, in authenticating the information handling system, the method further comprises validating the second authentication certificate (see Roy ¶48, validating authentication certificate was issued by a trusted certificate authority).
Similar rationales applied as above to combine the cited prior art references.
Claim(s) 2-4, 9-10, 12-14 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Parasseeri US Pub. No.: 2022/0191254 A1 in view of Roy et al. US Pub.: 2023/0336530 A1 as applied above to independent claims 1 and 11 and further in view of Maheve et al. US Pub. No.: 2022/0272117 A1 (hereinafter Maheve)
As to claim 2, the combination of Parasseeri and Roy does not explicitly disclose but the analogous art Maheve discloses the edge computing network of claim 1, wherein, in response to opening the predetermined network port, the endpoint device is further configured to provide a second outbound request associated with one of a plurality of WebSockets instantiated on the information handling system to the endpoint device (see Maheve ¶¶95-97, gateway 210 may be configured with a reverse proxy 218, a WebSocket service 212)
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the invention, to modify the proxy relay implementation for client server connections over wide area network disclosed by Parasseeri and a framework for configurable per-service security settings in a proxy disclosed by Roy to include deployments of WebSocket-type connections, as thought by Maheve. A person with ordinary skill in the art would have been motivated to include WebSocket connection to achieve a persistent two-way communication and enhance reliability.
As to claim 3, the combination of Parasseeri, Roy and Maheve discloses the edge computing network of claim 2, wherein the first reverse proxy is further configured to receive the second outbound request and to forward the second outbound request to the particular WebSocket(see Maheve ¶¶95-97, the reverse proxy 218 may allow the WebSocket traffic to flow to the WebSocket server 212 if the user has been authenticated. The WebSocket server 212 may apply further authorization checks to see if the user is permitted access to the protected resource 214).
As to claim 4, the combination of Parasseeri and Roy does not explicitly disclose but the analogous art Maheve discloses the edge computing network of claim 1, wherein, in response to opening the predetermined network port, the information handling system is configured to provide an inbound request to the endpoint device, the inbound request to direct the operation of the endpoint device (see Maheve ¶¶97 104, traffic from the protected resource 214 may be communicated over the established secure channel to the agent 252 where it is converted to application-specific form and delivered to the application 228 executing on the endpoint 144).
Similar rationales applied as above to combine the cited prior art references.
As to claim 9, the combination of Parasseeri and Roy does not explicitly disclose but the analogous art Maheve discloses the edge computing network of claim 1, wherein:
in response to opening the predetermined network port, the information handling system is further configured to provide an inbound request to the endpoint device (see Maheve ¶¶97 104, the endpoint agent, such as a local security agent 252 on the endpoint 144 may establish a tunnel interface with the WebSocket service 212 of the gateway 210 so that traffic for the protected resource 214 can be sent over an encrypted WebSocket channel) ; and
the endpoint device includes a control plane and a data plane, and is further configured to determine that the inbound request is addressed to one of the control plane and the data plane (see Fig. 4 and ¶94, data plane traffic and control plane configuration and management).
Similar rationales applied as above to combine the cited prior art references.
As to claim 10 , the combination of Parasseeri, Roy and Maheve discloses the edge computing network of claim 9, wherein the endpoint device is further configured to allocate bandwidth to the control plane and to the data plane based upon predetermined percentages (see Maheve ¶¶45 94, access policy to manage data plane and control plane network bandwidth).
Same rational as above is applied to combine the cited prior art references.
As to claim 19, the combination of Parasseeri and Roy does not explicitly disclose but the analogous art Maheve discloses the edge computing network of claim 1, further comprising: sending a second inbound request to the endpoint device (see Maheve ¶¶97 104, the endpoint agent, such as a local security agent 252 on the endpoint 144 may establish a tunnel interface with the WebSocket service 212 of the gateway 210 so that traffic for the protected resource 214 can be sent over an encrypted WebSocket channel); and
determining, by the endpoint device that the inbound request is addressed to one of a control plane and the data plane of the endpoint device (see Fig. 4 and ¶94, data plane traffic and control plane configuration and management).
Similar rationales applied as above to combine the cited prior art references.
As to claim 12 , the combination of Parasseeri and Roy does not explicitly disclose but the analogous art Maheve discloses the combination of Parasseeri, Roy and Maheve discloses the method of claim 11, wherein, in response to opening the predetermined network port, the method further comprises sending, by the endpoint device, a second outbound request associated with one of a plurality of WebSockets instantiated on the information handling system to the endpoint device (see Maheve ¶¶95-97, the reverse proxy 218 may allow the WebSocket traffic to flow to the WebSocket server 212 if the user has been authenticated. The WebSocket server 212 may apply further authorization checks to see if the user is permitted access to the protected resource 214).
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the invention, to modify the proxy relay implementation for client server connections over wide area network disclosed by Parasseeri and a framework for configurable per-service security settings in a proxy disclosed by Roy to include deployments of WebSocket-type connections, as thought by Maheve. A person with ordinary skill in the art would have been motivated to include WebSocket connection to achieve a persistent two-way communication and enhance reliability.
As to claim 13, the combination of Parasseeri, Roy and Maheve discloses the method of claim 12, further comprising: receiving, by the first reverse proxy, the second outbound request; and forwarding the second outbound request to the particular WebSocket (see Maheve ¶¶95-97, the reverse proxy 218 may allow the WebSocket traffic to flow to the WebSocket server 212 if the user has been authenticated. The WebSocket server 212 may apply further authorization checks to see if the user is permitted access to the protected resource 214).
Similar rationales applied as above to combine the cited prior art references.
As to claim 14, the combination of Parasseeri and Roy does not explicitly disclose but the analogous art Maheve discloses the method of claim 11, wherein, in response to opening the predetermined network port, the method further comprises sending an inbound request to the endpoint device, the inbound request to direct the operation of the endpoint device (see Maheve ¶¶97 104, traffic from the protected resource 214 may be communicated over the established secure channel to the agent 252 where it is converted to application-specific form and delivered to the application 228 executing on the endpoint 144).
Similar rationales applied as above to combine the cited prior art references.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Parasseeri US Pub. No.: 2022/0191254 A1 in view of Roy et al. US Pub.: 2023/0336530 A1 and further in view of Maheve et al. US Pub. No.: 2022/0272117 A1 (hereinafter Maheve)
Parasseeri:
As to claim 20, an edge compute network, comprising:
an endpoint device including a network interface having a plurality of network port and configured to provide a first outbound request on a predetermined network port(see Parasseeri, Fig. 1 and ¶48, client device 102 makes a first connection and connects to the relay reverse proxy service (connection D) on port 443. The messages are sent to the relay manager 122 on port 443. The receiver uses ports in the range of 5000-5999 to connect to the relay instance 128 [i.e. endpoint device/client device including network interface/110 having a plurality network ports/ ports 443, and 500-599 ), wherein each network port is configured to not respond to unsolicited incoming traffic (First, see applicant’s own disclosure ¶16, Connectivity between ECE 110 and EO 130 is directed in that the ECE is configured to initiate the connectivity with the EO via the dedicated port (port 443), but to not respond to unsolicited incoming traffic, [i.e. the recited endpoint device is the Edge Compute Endpoint (ECE)]). (see Parasseeri Figs. 1-3 and ¶¶2138 48 65 71-72, the client 102 attempts to connect via the network no to the receiver 124 on a non-standard port (non-443 port) other than via connections B and D. Therefore, because of the blocking over the non-standard (non-443) port by a VPN/firewall the request is denied. The relay backend server 116 service uses a port in the range of 5000-5750 to connect to the receiver 124 [i.e. unsolicited incoming traffic on ports 5000-5999 blocked]), wherein the endpoint device is configured to establish network connections on only the predetermined network port (see Parasseeri ¶37, all secure transfers are done using port 443, the standard port for HTTPS traffic [i.e. establishing network connection on only the predetermined network port] ¶38, the present disclosure describes a client that can be paired with a server and receiver using network transport security (TLS). The TLS can be negotiated over port 80 or port 443. Either port 80 or port 443 can be used in combination with a TLS reverse proxy for the handshake; ¶39, client us configured with a browser is implemented for the browsers to act on the initial assumption that port 443 will be used first for an attempted connection, then the port 80 will be tried [i.e. only Port 443 and 80 are used and both are predetermined network ports to establish network connections]); and
an information handling system including a first reverse proxy and a second reverse proxy (see Parasseeri Figs. 1-3 and ¶¶38 72, Client 102 connects to relay reverse Proxy service (NodeJS) [i.e. first reverse proxy]…the relay reverse proxy service 132 connects to a Relay Instance 128 [i.e. second reverse proxy]), and configured to instantiate an endpoint orchestrator, the first reverse proxy configured to receive the first outbound request on the predetermined network port and to provide the first outbound request to the second reverse proxy, the second reverse proxy configured to provide the first outbound request to the endpoint orchestrator (see Parasseeri Figs. 1-3 , ¶¶48 64 77, establishing the two connections of a connection between the client 102 and relay reverse proxy (D)[i.e., first reverse proxy], and another connection between the receiver 124 and relay reverse proxy 132 using the relay instance 128 (function 314)[i.e. second reverse proxy]), and
thereby establishing an authenticated network connection only on the predetermined network port (see Parasseeri ¶¶36-39, the present disclosure describes a client that can be paired with a server and receiver using network transport security (TLS). The TLS can be negotiated over port 80 or port 443 [i.e. establishing TLS network connection is authenticated network connection only] )
Parasseeri does not explicitly disclose but the analogues art Roy discloses:
the endpoint orchestrator configured to authenticate the endpoint device based upon the first outbound request and provide authentication information to the endpoint device to authenticate the information handling system to the endpoint device (see Roy ¶25, two-way authentication (or “mutual authentication”), as used herein, refers to a process in which a client device validates a server certificate of a service or back-end device, and the service or back-end device validates a client certificate of the client device);
wherein the endpoint device is further configured to authenticate the information handling system based upon the authentication information, and to open the predetermined network port to the information handling system in response to authenticating the information handling system (see Roy ¶25, two-way authentication (or “mutual authentication”), as used herein, refers to a process in which a client device validates a server certificate of a service or back-end device, and the service or back-end device validates a client certificate of the client device);
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the invention, to modify the proxy relay implementation for client server connections over wide area network disclosed by Parasseeri to include authentication of endpoint system before opening/connecting the predetermined network port, as thought by Roy. A person with ordinary skill in the art would have been motivated to authenticate the communication devices when connecting to any service that requires mutual or two-way transport layer security (TLS) and enhance security.
The combination of Parasseeri and Roy does not explicitly disclose but the analogues art Maheve discloses:
wherein, in response to opening the predetermined network port, the endpoint device is further configured to provide a second outbound request associated with one of a plurality of WebSockets instantiated on the information handling system to the endpoint device (see Maheve ¶¶83-85 and 97, ensuring integrity of WebSocket-type connections in a range of deployments, including deployments in which WebSocket-type connections are routinely refreshed); and
wherein, in response to opening the predetermined network port, the information handling system is configured to provide an inbound request to the endpoint device, the inbound request to direct the operation of the endpoint device (see Maheve ¶¶97 104, traffic from the protected resource 214 may be communicated over the established secure channel to the agent 252 where it is converted to application-specific form and delivered to the application 228 executing on the endpoint 144).
Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the invention, to modify the proxy relay implementation for client server connections over wide area network disclosed by Parasseeri and a framework for configurable per-service security settings in a proxy disclosed by Roy to include deployments of WebSocket-type connections, as thought by Maheve. A person with ordinary skill in the art would have been motivated to include WebSocket connection to achieve a persistent two-way communication and enhance reliability.
Conclusion
THIS ACTION IS MADE FINAL. 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 NEGA WOLDEMARIAM whose telephone number is (571)270-7478. The examiner can normally be reached Monday to Friday, 8am-5pm.
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, Cathy Thiaw can be reached at 5712701138. 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.
NEGA . WOLDEMARIAM
Examiner
Art Unit 2407
/N.W/ Examiner, Art Unit 2407
/Catherine Thiaw/ Supervisory Patent Examiner, Art Unit 2407 1/29/2026
Prosecution Insights