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 .
Summary
This action is a responsive to the application filed on 12/6/2023.
Claims 1-20 are pending and have been examined.
Claims 1-20 are rejected.
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on 3/14/2024, 11/06/2024, 4/17/2025, 8/14/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Examiner’s Note
For purposes of the 35 USC § 101 signals per se analysis with respect to claims 15-20 set forth below, the computer readable storage medium is interpreted to exclude all transitory media in view ¶ [0088] of the specification. As such, the computer readable storage medium is construed to not include transitory signals, which are not statutory patentable subject matter per se under 35 USC § 101 signals per se.
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.
The factual inquiries 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 6-10, 13-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Handa et al. (US 20160088023 A1) and further in view of Holm et al. (US 20230412570 A1) and Tribble et al. (US 20160173280 A1).
As to claim 1, Handa et al. teaches a method for error handling while establishing end-to-end encrypted communications with a client, the method comprising: receiving, at a reverse proxy of a cloud service over a first transport layer connection (See ¶ [0103], Teaches that a web service request may be received by an intermediary computing system or application, such as reverse proxy server 420. As noted above, reverse proxy server 420 may be implemented as an intermediary server device and/or application between a trusted internal network 460 and one or more untrusted external networks. Therefore, the reverse proxy server 420 may intercept messages transmitted by client endpoints (e.g., client devices 410) and intended for server endpoint devices (e.g., computer server hosting backend web services and/or applications 430), or vice versa.),
a client request that includes a resource identifier associated with an on-premises resource (See ¶ [0108], Teaches that In order to determine in step 602 whether or not the request is directed to a REST resource 528 exposed by a REST service 423/523 in the reverse proxy server 420, the request may be parsed and analyzed to identify the request destination and relevant portions of the message header and/or body. For example, if the request is an HTTP request directed to a URL that corresponds to a REST resource within a WADL file (or other web service description data) for a REST service 423, then the request handler 421 may determine that the request is directed to a REST resource 528 exposed by the reverse proxy server 420 (602:Yes). Alternatively, if the request is an invalid request, a SOAP request, a request for normal web content, or a request directed to a REST resource that is not accessible via reverse proxy server 420, then the request handler 421 may determine that the request is not directed to a REST resource 528 exposed by the reverse proxy server 420 (602:No).);
determining, based at least on the resource identifier, that an error prevents forwarding of the client request to the on-premises resource (See ¶ [0112], Teaches that one or more backend web service calls may be determined during handling of the request, for example, during the execution of the REST resource 528 within the reverse proxy server 420. In some embodiments, a software hook and/or other customized software code may be inserted into the REST resource 528 when the resource is created. Such software hooks and/or customized software code may identify backend REST services 430 and resources, as well as individual operations (or methods), parameters, and other data that may be transmitted in a call to a backend web service 430. When the REST resource 528 on the reverse proxy server 420 is invoked to handle the request, the software hook and/or customized software code may be executed and the call to the backend web service 430 may be generated.).
However, it does not expressly teach the details of transmitting, to an error handling service over a second transport layer connection, an application layer request comprising error handling information, the error handling information enabling the error handling service to establish a secure communications channel with the client over the second transport layer connection and the first transport layer connection; receiving, from the error handling service, an encrypted response comprising an error message generated based at least on the error handling information; and forwarding, to the client, the encrypted response.
Holm et al., from analogous art, teaches transmitting, to an error handling service over a second transport layer connection, an application layer request comprising error handling information (See ¶ [0053], Teaches that The proxying API façade service can provide an error handling interface 2450, which can provide a uniform, and extensible, error handling interface for all mapped proxy endpoints, mapped endpoints, or proxy endpoints (collectively “mapped proxy endpoints”). The error handling interface 2450 is decoupled from the proxy subject API 2700. This can enable developer users, client devices/clients, or combinations thereof to leverage proxy subject error handling where appropriate and override or extend as needed. This can provide a consistent interface for error reporting to all proxy endpoint clients, creating opportunities for more easily encapsulating cross cutting reporting and/or interventions on the client side. Moreover, all errors can be reported via an auditor component 2145 to the audit service systems server 2400. This can allow for error rate analysis, broad scale defect triage, and other error analysis.);
receiving, from the error handling service, an encrypted response comprising an error message generated based at least on the error handling information; and forwarding, to the client, the encrypted response (See ¶ [0053], Teaches that The proxying API façade service can provide an error handling interface 2450, which can provide a uniform, and extensible, error handling interface for all mapped proxy endpoints, mapped endpoints, or proxy endpoints (collectively “mapped proxy endpoints”). The error handling interface 2450 is decoupled from the proxy subject API 2700. This can enable developer users, client devices/clients, or combinations thereof to leverage proxy subject error handling where appropriate and override or extend as needed. This can provide a consistent interface for error reporting to all proxy endpoint clients, creating opportunities for more easily encapsulating cross cutting reporting and/or interventions on the client side. Moreover, all errors can be reported via an auditor component 2145 to the audit service systems server 2400. This can allow for error rate analysis, broad scale defect triage, and other error analysis.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Holm et al. into Handa et al. in order to quickly deploy secure, documented proxying API façades for selected proxy subject API endpoints (See Holm et al. ¶ [0025]).
However, it does not expressly teach the details of a second transport layer connection; the error handling information enabling the error handling service to establish a secure communications channel with the client over the second transport layer connection and the first transport layer connection.
Tribble et al., from analogous art, teaches a second transport layer connection (See ¶ [0048], Teaches that a different encryption handshake 409 is performed between the first server 404 and the second server 406 before the session key and request are sent from the first server 404 to the second server 406);
the error handling information enabling the error handling service to establish a secure communications channel with the client over the second transport layer connection and the first transport layer connection (See ¶¶ [0047]-[0048], Teaches that a different encryption handshake 409 is performed between the first server 404 and the second server 406 before the session key and request are sent from the first server 404 to the second server 406. That is, a different encryption handshake 409 is performed between the first server 404 and the second server 406 before the session key and request are sent from the first server 404 to the second server 406.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Tribble et al. into the combination of Handa et al. and Holm et al. in order to allow a client device to securely communicate data with multiple computing devices using one encryption key (See Tribble et al. ¶ [0014]).
As to claim 2, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the method according to claim 1 above. However, it does not expressly teach the details of wherein the encrypted response is encrypted with security information associated with the on-premises resource.
Tribble et al., from analogous art, teaches wherein the encrypted response is encrypted with security information associated with the on-premises resource (See ¶ [0049], Teaches that The second server 406 can decrypt the request 412 using the session key. After processing the request 412, the second server 406 can encrypt data responsive to the request 412 using the session key, and can send the encrypted data back to the first server 416. The first server 404 can send the encrypted data to the client device 418. The client device 402 can decrypt the data using the session key to view its contents).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Tribble et al. into the combination of Handa et al. and Holm et al. and Tribble et al. in order to allow a client device to securely communicate data with multiple computing devices using one encryption key (See Tribble et al. ¶ [0014]).
As to claim 3, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the method according to claim 2 above. However, it does not expressly teach the details of wherein the security information comprises: a security certificate generated during onboarding of the on-premises resource, and stored at both a location accessible to the error handling service and at the on-premises resource.
Tribble et al., from analogous art, teaches wherein the security information comprises: a security certificate generated during onboarding of the on-premises resource, and stored at both a location accessible to the error handling service and at the on-premises resource (See ¶¶ [0021], [0031], Fig. 2, Teaches that the client 102 and the web server 106 each use the pre-master secret to generate a master secret and a session key 112 (“master session key”). The master session key 112 can be used to encrypt and decrypt data that is communicated between the client 102 and the web server 106. Data that is communicated over the secure communication channel is encrypted and is therefore not able to be accessed by a third-party, as it typically would be had the data been communicated in clear text. The reverse proxy 206 sends a copy of the master session key 212 to the web server 208 for using in encrypting data that is communicated between the reverse proxy 206 and the web server 208. Optionally, the reverse proxy 206 can encrypt the master session key 212, for example, using the web server's 208 public key before sending to provide added security for the master session key 212. Other ways of encrypting the master session key 212 are possible using generally known encrypting techniques.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Tribble et al. into the combination of Handa et al. and Holm et al. and Tribble et al. in order to allow a client device to securely communicate data with multiple computing devices using one encryption key (See Tribble et al. ¶ [0014]).
As to claim 6, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the method according to claim 1 above. Handa et al. further teaches wherein the on-premises resource comprises: a computing cluster associated with a customer of the cloud service and connected to the cloud service via a hybrid connection (See ¶¶ [0030], [0025], [0076], Teaches that Server 112 may be composed of one or more general purpose computers, specialized server computers (including, by way of example, PC (personal computer) servers, UNIX® servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other appropriate arrangement and/or combination. In various embodiments, server 112 may be adapted to run one or more services or software applications described in the foregoing disclosure. For example, server 112 may correspond to a server for performing processing described above according to an embodiment of the present disclosure. Server 112 may be adapted to run one or more services or software applications provided by one or more of the components of the system. In some embodiments, these services may be offered as web-based or cloud services or under a Software as a Service (SaaS) model to the users of client computing devices 102, 104, 106, and/or 108. Users operating client computing devices 102, 104, 106, and/or 108 may in turn utilize one or more client applications to interact with server 112 to utilize the services provided by these components. Communications subsystem 324 serves as an interface for receiving data from and transmitting data to other systems from computer system 300. For example, communications subsystem 324 may enable computer system 300 to connect to one or more devices via the Internet. In some embodiments communications subsystem 324 can include radio frequency (RF) transceiver components for accessing wireless voice and/or data networks (e.g., using cellular telephone technology, advanced data network technology, such as 3 G, 4 G or EDGE (enhanced data rates for global evolution), WiFi (IEEE 802.11 family standards, or other mobile communication technologies, or any combination thereof), global positioning system (GPS) receiver components, and/or other components. In some embodiments communications subsystem 324 can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.).
As to claim 7, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the method according to claim 1 above. However, it does not expressly teach the details of further comprising: retrieving, by the error handling service, security information associated with the on-premises resource; generating, by the error handling service, the error message based on the error handling information; and encrypting, by the error handling service, the error message using the security information associated with the on-premises resource.
Holm et al., from analogous art, teaches further comprising: retrieving, by the error handling service, security information associated with the on-premises resource; generating, by the error handling service, the error message based on the error handling information (See ¶ [0051], Teaches that The proxying API façade service can provide an error handling interface 2450, which can provide a uniform, and extensible, error handling interface for all mapped proxy endpoints, mapped endpoints, or proxy endpoints (collectively “mapped proxy endpoints”). The error handling interface 2450 is decoupled from the proxy subject API 2700. This can enable developer users, client devices/clients, or combinations thereof to leverage proxy subject error handling where appropriate and override or extend as needed. This can provide a consistent interface for error reporting to all proxy endpoint clients, creating opportunities for more easily encapsulating cross cutting reporting and/or interventions on the client side. Moreover, all errors can be reported via an auditor component 2145 to the audit service systems server 2400. This can allow for error rate analysis, broad scale defect triage, and other error analysis .
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Holm et al. into the combination of Handa et al. and Holm et al. and Tribble et al. in order to quickly deploy secure, documented proxying API façades for selected proxy subject API endpoints (See Holm et al. ¶ [0025]).
However, it does not expressly teach the details of encrypting, by the error handling service, the error message using the security information associated with the on-premises resource.
Tribble et al., from analogous art, teaches encrypting, by the error handling service, the error message using the security information associated with the on-premises resource (See ¶ [0053], Teaches that The proxying API façade service can provide an error handling interface 2450, which can provide a uniform, and extensible, error handling interface for all mapped proxy endpoints, mapped endpoints, or proxy endpoints (collectively “mapped proxy endpoints”). The error handling interface 2450 is decoupled from the proxy subject API 2700. This can enable developer users, client devices/clients, or combinations thereof to leverage proxy subject error handling where appropriate and override or extend as needed. This can provide a consistent interface for error reporting to all proxy endpoint clients, creating opportunities for more easily encapsulating cross cutting reporting and/or interventions on the client side. Moreover, all errors can be reported via an auditor component 2145 to the audit service systems server 2400. This can allow for error rate analysis, broad scale defect triage, and other error analysis).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Tribble et al. into the combination of Handa et al. and Holm et al. and Tribble et al. in order to allow a client device to securely communicate data with multiple computing devices using one encryption key (See Tribble et al. ¶ [0014]).
As to claim 8, Handa et al. teaches a system for error handling while establishing end-to-end encrypted communications with a client, the system comprising: a processor; a memory device comprising program code structured to cause the processor to: receive, at a reverse proxy of a cloud service over a first transport layer connection (See ¶ [0103], Teaches that a web service request may be received by an intermediary computing system or application, such as reverse proxy server 420. As noted above, reverse proxy server 420 may be implemented as an intermediary server device and/or application between a trusted internal network 460 and one or more untrusted external networks. Therefore, the reverse proxy server 420 may intercept messages transmitted by client endpoints (e.g., client devices 410) and intended for server endpoint devices (e.g., computer server hosting backend web services and/or applications 430), or vice versa.),
a client request that includes a resource identifier associated with an on-premises resource (See ¶ [0108], Teaches that In order to determine in step 602 whether or not the request is directed to a REST resource 528 exposed by a REST service 423/523 in the reverse proxy server 420, the request may be parsed and analyzed to identify the request destination and relevant portions of the message header and/or body. For example, if the request is an HTTP request directed to a URL that corresponds to a REST resource within a WADL file (or other web service description data) for a REST service 423, then the request handler 421 may determine that the request is directed to a REST resource 528 exposed by the reverse proxy server 420 (602:Yes). Alternatively, if the request is an invalid request, a SOAP request, a request for normal web content, or a request directed to a REST resource that is not accessible via reverse proxy server 420, then the request handler 421 may determine that the request is not directed to a REST resource 528 exposed by the reverse proxy server 420 (602:No).);
determine, based at least on the resource identifier, that an error prevents forwarding of the client request to the on-premises resource (See ¶ [0112], Teaches that one or more backend web service calls may be determined during handling of the request, for example, during the execution of the REST resource 528 within the reverse proxy server 420. In some embodiments, a software hook and/or other customized software code may be inserted into the REST resource 528 when the resource is created. Such software hooks and/or customized software code may identify backend REST services 430 and resources, as well as individual operations (or methods), parameters, and other data that may be transmitted in a call to a backend web service 430. When the REST resource 528 on the reverse proxy server 420 is invoked to handle the request, the software hook and/or customized software code may be executed and the call to the backend web service 430 may be generated.).
However, it does not expressly teach the details of transmit, to an error handling service over a second transport layer connection, an application layer request comprising error handling information, the error handling information enabling the error handling service to establish a secure communications channel with the client over the second transport layer connection and the first transport layer connection; receive, from the error handling service, an encrypted response comprising an error message generated based at least on the error handling information; and forward, to the client, the encrypted response.
Holm et al., from analogous art, teaches transmit, to an error handling service over a second transport layer connection, an application layer request comprising error handling information (See ¶ [0053], Teaches that The proxying API façade service can provide an error handling interface 2450, which can provide a uniform, and extensible, error handling interface for all mapped proxy endpoints, mapped endpoints, or proxy endpoints (collectively “mapped proxy endpoints”). The error handling interface 2450 is decoupled from the proxy subject API 2700. This can enable developer users, client devices/clients, or combinations thereof to leverage proxy subject error handling where appropriate and override or extend as needed. This can provide a consistent interface for error reporting to all proxy endpoint clients, creating opportunities for more easily encapsulating cross cutting reporting and/or interventions on the client side. Moreover, all errors can be reported via an auditor component 2145 to the audit service systems server 2400. This can allow for error rate analysis, broad scale defect triage, and other error analysis.);
receive, from the error handling service, an encrypted response comprising an error message generated based at least on the error handling information; and forward, to the client, the encrypted response (See ¶ [0053], Teaches that The proxying API façade service can provide an error handling interface 2450, which can provide a uniform, and extensible, error handling interface for all mapped proxy endpoints, mapped endpoints, or proxy endpoints (collectively “mapped proxy endpoints”). The error handling interface 2450 is decoupled from the proxy subject API 2700. This can enable developer users, client devices/clients, or combinations thereof to leverage proxy subject error handling where appropriate and override or extend as needed. This can provide a consistent interface for error reporting to all proxy endpoint clients, creating opportunities for more easily encapsulating cross cutting reporting and/or interventions on the client side. Moreover, all errors can be reported via an auditor component 2145 to the audit service systems server 2400. This can allow for error rate analysis, broad scale defect triage, and other error analysis.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Holm et al. into Handa et al. in order to quickly deploy secure, documented proxying API façades for selected proxy subject API endpoints (See Holm et al. ¶ [0025]).
However, it does not expressly teach the details of a second transport layer connection; the error handling information enabling the error handling service to establish a secure communications channel with the client over the second transport layer connection and the first transport layer connection.
Tribble et al., from analogous art, teaches a second transport layer connection (See ¶ [0048], Teaches that a different encryption handshake 409 is performed between the first server 404 and the second server 406 before the session key and request are sent from the first server 404 to the second server 406);
the error handling information enabling the error handling service to establish a secure communications channel with the client over the second transport layer connection and the first transport layer connection (See ¶¶ [0047]-[0048], Teaches that a different encryption handshake 409 is performed between the first server 404 and the second server 406 before the session key and request are sent from the first server 404 to the second server 406. That is, a different encryption handshake 409 is performed between the first server 404 and the second server 406 before the session key and request are sent from the first server 404 to the second server 406.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Tribble et al. into the combination of Handa et al. and Holm et al. in order to allow a client device to securely communicate data with multiple computing devices using one encryption key (See Tribble et al. ¶ [0014]).
As to claim 9, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the system according to claim 8 above. However, it does not expressly teach the details of wherein the encrypted response is encrypted using security information associated with the on-premises resource.
Tribble et al., from analogous art, teaches wherein the encrypted response is encrypted using security information associated with the on-premises resource (See ¶ [0049], Teaches that The second server 406 can decrypt the request 412 using the session key. After processing the request 412, the second server 406 can encrypt data responsive to the request 412 using the session key, and can send the encrypted data back to the first server 416. The first server 404 can send the encrypted data to the client device 418. The client device 402 can decrypt the data using the session key to view its contents).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Tribble et al. into the combination of Handa et al. and Holm et al. and Tribble et al. in order to allow a client device to securely communicate data with multiple computing devices using one encryption key (See Tribble et al. ¶ [0014]).
As to claim 10, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the system according to claim 9 above. However, it does not expressly teach the details of wherein the security information comprises: a security certificate generated during onboarding of the on-premises resource, and stored at both a location accessible to the error handling service and at the on-premises resource.
Tribble et al., from analogous art, teaches wherein the security information comprises: a security certificate generated during onboarding of the on-premises resource, and stored at both a location accessible to the error handling service and at the on-premises resource (See ¶¶ [0021], [0031], Fig. 2, Teaches that the client 102 and the web server 106 each use the pre-master secret to generate a master secret and a session key 112 (“master session key”). The master session key 112 can be used to encrypt and decrypt data that is communicated between the client 102 and the web server 106. Data that is communicated over the secure communication channel is encrypted and is therefore not able to be accessed by a third-party, as it typically would be had the data been communicated in clear text. The reverse proxy 206 sends a copy of the master session key 212 to the web server 208 for using in encrypting data that is communicated between the reverse proxy 206 and the web server 208. Optionally, the reverse proxy 206 can encrypt the master session key 212, for example, using the web server's 208 public key before sending to provide added security for the master session key 212. Other ways of encrypting the master session key 212 are possible using generally known encrypting techniques.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Tribble et al. into the combination of Handa et al. and Holm et al. and Tribble et al. in order to allow a client device to securely communicate data with multiple computing devices using one encryption key (See Tribble et al. ¶ [0014]).
As to claim 13, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the system according to claim 8 above. Handa et al. further teaches wherein the on-premises resource comprises: a computing cluster associated with a customer of the cloud service and connected to the cloud service via a hybrid connection (See ¶¶ [0030], [0025], [0076], Teaches that Server 112 may be composed of one or more general purpose computers, specialized server computers (including, by way of example, PC (personal computer) servers, UNIX® servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other appropriate arrangement and/or combination. In various embodiments, server 112 may be adapted to run one or more services or software applications described in the foregoing disclosure. For example, server 112 may correspond to a server for performing processing described above according to an embodiment of the present disclosure. Server 112 may be adapted to run one or more services or software applications provided by one or more of the components of the system. In some embodiments, these services may be offered as web-based or cloud services or under a Software as a Service (SaaS) model to the users of client computing devices 102, 104, 106, and/or 108. Users operating client computing devices 102, 104, 106, and/or 108 may in turn utilize one or more client applications to interact with server 112 to utilize the services provided by these components. Communications subsystem 324 serves as an interface for receiving data from and transmitting data to other systems from computer system 300. For example, communications subsystem 324 may enable computer system 300 to connect to one or more devices via the Internet. In some embodiments communications subsystem 324 can include radio frequency (RF) transceiver components for accessing wireless voice and/or data networks (e.g., using cellular telephone technology, advanced data network technology, such as 3 G, 4 G or EDGE (enhanced data rates for global evolution), WiFi (IEEE 802.11 family standards, or other mobile communication technologies, or any combination thereof), global positioning system (GPS) receiver components, and/or other components. In some embodiments communications subsystem 324 can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.).
As to claim 14, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the system according to claim 8 above. However, it does not expressly teach the details of wherein the program code is further structured to cause the processor to: retrieve security information associated with the on-premises resource; generate the error message based on the error handling information; and encrypt the error message using the security information associated with the on-premises resource.
Holm et al., from analogous art, teaches wherein the program code is further structured to cause the processor to: retrieve security information associated with the on-premises resource; generate the error message based on the error handling information (See ¶ [0051], Teaches that The proxying API façade service can provide an error handling interface 2450, which can provide a uniform, and extensible, error handling interface for all mapped proxy endpoints, mapped endpoints, or proxy endpoints (collectively “mapped proxy endpoints”). The error handling interface 2450 is decoupled from the proxy subject API 2700. This can enable developer users, client devices/clients, or combinations thereof to leverage proxy subject error handling where appropriate and override or extend as needed. This can provide a consistent interface for error reporting to all proxy endpoint clients, creating opportunities for more easily encapsulating cross cutting reporting and/or interventions on the client side. Moreover, all errors can be reported via an auditor component 2145 to the audit service systems server 2400. This can allow for error rate analysis, broad scale defect triage, and other error analysis .
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Holm et al. into the combination of Handa et al. and Holm et al. and Tribble et al. in order to quickly deploy secure, documented proxying API façades for selected proxy subject API endpoints (See Holm et al. ¶ [0025]).
However, it does not expressly teach the details of encrypt the error message using the security information associated with the on-premises resource.
Tribble et al., from analogous art, teaches encrypt the error message using the security information associated with the on-premises resource (See ¶ [0053], Teaches that The proxying API façade service can provide an error handling interface 2450, which can provide a uniform, and extensible, error handling interface for all mapped proxy endpoints, mapped endpoints, or proxy endpoints (collectively “mapped proxy endpoints”). The error handling interface 2450 is decoupled from the proxy subject API 2700. This can enable developer users, client devices/clients, or combinations thereof to leverage proxy subject error handling where appropriate and override or extend as needed. This can provide a consistent interface for error reporting to all proxy endpoint clients, creating opportunities for more easily encapsulating cross cutting reporting and/or interventions on the client side. Moreover, all errors can be reported via an auditor component 2145 to the audit service systems server 2400. This can allow for error rate analysis, broad scale defect triage, and other error analysis).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Tribble et al. into the combination of Handa et al. and Holm et al. and Tribble et al. in order to allow a client device to securely communicate data with multiple computing devices using one encryption key (See Tribble et al. ¶ [0014]).
As to claim 15, Handa et al. teaches a computer-readable storage medium comprising computer-executable instructions for error handling while establishing end-to-end encrypted communications with a client, the computer-executable instructions, when executed by a processor, cause the processor to: receive, at a reverse proxy of a cloud service, a client request that includes a resource identifier associated with an on-premises resource (See ¶¶ [0103], [0108], Teaches that a web service request may be received by an intermediary computing system or application, such as reverse proxy server 420. As noted above, reverse proxy server 420 may be implemented as an intermediary server device and/or application between a trusted internal network 460 and one or more untrusted external networks. Therefore, the reverse proxy server 420 may intercept messages transmitted by client endpoints (e.g., client devices 410) and intended for server endpoint devices (e.g., computer server hosting backend web services and/or applications 430), or vice versa. In order to determine in step 602 whether or not the request is directed to a REST resource 528 exposed by a REST service 423/523 in the reverse proxy server 420, the request may be parsed and analyzed to identify the request destination and relevant portions of the message header and/or body. For example, if the request is an HTTP request directed to a URL that corresponds to a REST resource within a WADL file (or other web service description data) for a REST service 423, then the request handler 421 may determine that the request is directed to a REST resource 528 exposed by the reverse proxy server 420 (602:Yes). Alternatively, if the request is an invalid request, a SOAP request, a request for normal web content, or a request directed to a REST resource that is not accessible via reverse proxy server 420, then the request handler 421 may determine that the request is not directed to a REST resource 528 exposed by the reverse proxy server 420 (602:No).);
determine, based at least on the resource identifier, that an error prevents forwarding of the client request to the on-premises resource (See ¶ [0112], Teaches that one or more backend web service calls may be determined during handling of the request, for example, during the execution of the REST resource 528 within the reverse proxy server 420. In some embodiments, a software hook and/or other customized software code may be inserted into the REST resource 528 when the resource is created. Such software hooks and/or customized software code may identify backend REST services 430 and resources, as well as individual operations (or methods), parameters, and other data that may be transmitted in a call to a backend web service 430. When the REST resource 528 on the reverse proxy server 420 is invoked to handle the request, the software hook and/or customized software code may be executed and the call to the backend web service 430 may be generated.).
However, it does not expressly teach the details of transmit, to an error handling service over a second transport layer connection, an application layer request comprising error handling information, the error handling information enabling the error handling service to establish a secure communications channel with the client over the second transport layer connection and the first transport layer connection; receive, from the error handling service, an encrypted response comprising an error message generated based at least on the error handling information; and forward, to the client, the encrypted response.
Holm et al., from analogous art, teaches transmit, to an error handling service over a second transport layer connection, an application layer request comprising error handling information (See ¶ [0053], Teaches that The proxying API façade service can provide an error handling interface 2450, which can provide a uniform, and extensible, error handling interface for all mapped proxy endpoints, mapped endpoints, or proxy endpoints (collectively “mapped proxy endpoints”). The error handling interface 2450 is decoupled from the proxy subject API 2700. This can enable developer users, client devices/clients, or combinations thereof to leverage proxy subject error handling where appropriate and override or extend as needed. This can provide a consistent interface for error reporting to all proxy endpoint clients, creating opportunities for more easily encapsulating cross cutting reporting and/or interventions on the client side. Moreover, all errors can be reported via an auditor component 2145 to the audit service systems server 2400. This can allow for error rate analysis, broad scale defect triage, and other error analysis.);
receive, from the error handling service, an encrypted response comprising an error message generated based at least on the error handling information; and forward, to the client, the encrypted response (See ¶ [0053], Teaches that The proxying API façade service can provide an error handling interface 2450, which can provide a uniform, and extensible, error handling interface for all mapped proxy endpoints, mapped endpoints, or proxy endpoints (collectively “mapped proxy endpoints”). The error handling interface 2450 is decoupled from the proxy subject API 2700. This can enable developer users, client devices/clients, or combinations thereof to leverage proxy subject error handling where appropriate and override or extend as needed. This can provide a consistent interface for error reporting to all proxy endpoint clients, creating opportunities for more easily encapsulating cross cutting reporting and/or interventions on the client side. Moreover, all errors can be reported via an auditor component 2145 to the audit service systems server 2400. This can allow for error rate analysis, broad scale defect triage, and other error analysis.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Holm et al. into Handa et al. in order to quickly deploy secure, documented proxying API façades for selected proxy subject API endpoints (See Holm et al. ¶ [0025]).
However, it does not expressly teach the details of a second transport layer connection; the error handling information enabling the error handling service to establish a secure communications channel with the client over the second transport layer connection and the first transport layer connection.
Tribble et al., from analogous art, teaches a second transport layer connection (See ¶ [0048], Teaches that a different encryption handshake 409 is performed between the first server 404 and the second server 406 before the session key and request are sent from the first server 404 to the second server 406);
the error handling information enabling the error handling service to establish a secure communications channel with the client over the second transport layer connection and the first transport layer connection (See ¶¶ [0047]-[0048], Teaches that a different encryption handshake 409 is performed between the first server 404 and the second server 406 before the session key and request are sent from the first server 404 to the second server 406. That is, a different encryption handshake 409 is performed between the first server 404 and the second server 406 before the session key and request are sent from the first server 404 to the second server 406.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Tribble et al. into the combination of Handa et al. and Holm et al. in order to allow a client device to securely communicate data with multiple computing devices using one encryption key (See Tribble et al. ¶ [0014]).
As to claim 16, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the computer-readable storage medium according to claim 15 above. However, it does not expressly teach the details of wherein the encrypted response is encrypted using security information associated with the on-premises resource.
Tribble et al., from analogous art, teaches wherein the encrypted response is encrypted using security information associated with the on-premises resource (See ¶ [0049], Teaches that The second server 406 can decrypt the request 412 using the session key. After processing the request 412, the second server 406 can encrypt data responsive to the request 412 using the session key, and can send the encrypted data back to the first server 416. The first server 404 can send the encrypted data to the client device 418. The client device 402 can decrypt the data using the session key to view its contents).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Tribble et al. into the combination of Handa et al. and Holm et al. and Tribble et al. in order to allow a client device to securely communicate data with multiple computing devices using one encryption key (See Tribble et al. ¶ [0014]).
As to claim 17, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the computer-readable storage medium according to claim 16 above. However, it does not expressly teach the details of wherein the security information comprises: a security certificate generated during onboarding of the on-premises resource, and stored at both a location accessible to the error handling service and at the on-premises resource.
Tribble et al., from analogous art, teaches wherein the security information comprises: a security certificate generated during onboarding of the on-premises resource, and stored at both a location accessible to the error handling service and at the on-premises resource (See ¶¶ [0021], [0031], Fig. 2, Teaches that the client 102 and the web server 106 each use the pre-master secret to generate a master secret and a session key 112 (“master session key”). The master session key 112 can be used to encrypt and decrypt data that is communicated between the client 102 and the web server 106. Data that is communicated over the secure communication channel is encrypted and is therefore not able to be accessed by a third-party, as it typically would be had the data been communicated in clear text. The reverse proxy 206 sends a copy of the master session key 212 to the web server 208 for using in encrypting data that is communicated between the reverse proxy 206 and the web server 208. Optionally, the reverse proxy 206 can encrypt the master session key 212, for example, using the web server's 208 public key before sending to provide added security for the master session key 212. Other ways of encrypting the master session key 212 are possible using generally known encrypting techniques.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Tribble et al. into the combination of Handa et al. and Holm et al. and Tribble et al. in order to allow a client device to securely communicate data with multiple computing devices using one encryption key (See Tribble et al. ¶ [0014]).
As to claim 20, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the computer-readable storage medium according to claim 15 above. Handa et al. further teaches wherein the on-premises resource comprises: a computing cluster associated with a customer of the cloud service and connected to the cloud service via a hybrid connection (See ¶¶ [0030], [0025], [0076], Teaches that Server 112 may be composed of one or more general purpose computers, specialized server computers (including, by way of example, PC (personal computer) servers, UNIX® servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other appropriate arrangement and/or combination. In various embodiments, server 112 may be adapted to run one or more services or software applications described in the foregoing disclosure. For example, server 112 may correspond to a server for performing processing described above according to an embodiment of the present disclosure. Server 112 may be adapted to run one or more services or software applications provided by one or more of the components of the system. In some embodiments, these services may be offered as web-based or cloud services or under a Software as a Service (SaaS) model to the users of client computing devices 102, 104, 106, and/or 108. Users operating client computing devices 102, 104, 106, and/or 108 may in turn utilize one or more client applications to interact with server 112 to utilize the services provided by these components. Communications subsystem 324 serves as an interface for receiving data from and transmitting data to other systems from computer system 300. For example, communications subsystem 324 may enable computer system 300 to connect to one or more devices via the Internet. In some embodiments communications subsystem 324 can include radio frequency (RF) transceiver components for accessing wireless voice and/or data networks (e.g., using cellular telephone technology, advanced data network technology, such as 3 G, 4 G or EDGE (enhanced data rates for global evolution), WiFi (IEEE 802.11 family standards, or other mobile communication technologies, or any combination thereof), global positioning system (GPS) receiver components, and/or other components. In some embodiments communications subsystem 324 can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.).
Claims 4-5, 11-12, 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Handa et al. (US 20160088023 A1) and Holm et al. (US 20230412570 A1) and Tribble et al. (US 20160173280 A1) and further in view of Rowe et al. (US 20220086215 A1).
As to claim 4, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the method according to claim 1 above. However, it does not expressly teach the details of wherein said determining, based at least on the resource identifier, that an error prevents forwarding of the client request to the on-premises resource comprises at least one of: determining that the on-premises resource is unreachable; determining that the resource identifier has expired; or determining that the resource identifier is invalid.
Rowe et al., from analogous art, teaches wherein said determining, based at least on the resource identifier, that an error prevents forwarding of the client request to the on-premises resource comprises at least one of: determining that the on-premises resource is unreachable; determining that the resource identifier has expired; or determining that the resource identifier is invalid (See ¶ [0101], Teaches that Client device 701 may include web client 704 and message handler 705. One or more components of client device 701 may be implemented with hardware, software, or a combination of both. Web client 704 may be any instance of application that is capable of making web requests. Web client 704 may be an HTTP client. For example, web client 704 may be a web browser, an email client, a calendar application, a social media application, a digital map application, a productivity application, a messaging application, a communications application, a database application, an information retrieval application, a microapp, etc. Web client 704 may be a desktop application or a mobile application. Message handler 705 may be a software and/or hardware module that handles messaging between web client 704 and web service 706 of server device 702. Message handler 705 may be, for example, an HTTP message handler (e.g., of HttpMessageHandler class) on the NET Framework developed by MICROSOFT CORPORATION of Redmond, Wash. Message handler 705 may be capable of performing the exponential moving average (EMA) function as well as storing and recalling EMA values. Web client 704 may use message handler 705 to invoke the make request (e.g., make HTTP request) function to send out a web request to web service 706. In response, message handler may use the EMA function to determine whether or not to throttle the web request. After message handler 705 sends out the web request (e.g., an HTTP request) to web service 706, message handler 705 may receive a web response (e.g., an HTTP response) from web service 706. Based on a timer that was initiated when the web request was sent out, message handler 705 may determine a response time for the web response. The response time may be recorded and an updated EMA value may be determined based on the response time. Message handler 705 may forward an external service response code (e.g., 200 OK, 400 Bad Request, 404 Not Found, etc.) to web client 704. If no response is received by message handler 705 before the timer expires, message handler 705 may return an error code (e.g., 408 Request Timeout) to web client 704.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Rowe et al. into the combination of Handa et al. and Holm et al. and Tribble et al. in order to better manage web requests and responses to improve user experience when the network condition deteriorates (See Rowe et al. ¶ [0003]).
As to claim 5, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the method according to claim 1 above. However, it does not expressly teach the details of wherein the application layer request comprises error handling information comprises: a Hypertext Transfer Protocol Secure (HTTPS) or a Hypertext Transfer Protocol (HTTP) message containing at least one of: a hostname of the on-premises resource, the error message, or a correlation identifier.
Rowe et al., from analogous art, teaches wherein the application layer request comprises error handling information comprises: a Hypertext Transfer Protocol Secure (HTTPS) or a Hypertext Transfer Protocol (HTTP) message containing at least one of: a hostname of the on-premises resource, the error message, or a correlation identifier (See ¶ [0101], Teaches that Client device 701 may include web client 704 and message handler 705. One or more components of client device 701 may be implemented with hardware, software, or a combination of both. Web client 704 may be any instance of application that is capable of making web requests. Web client 704 may be an HTTP client. For example, web client 704 may be a web browser, an email client, a calendar application, a social media application, a digital map application, a productivity application, a messaging application, a communications application, a database application, an information retrieval application, a microapp, etc. Web client 704 may be a desktop application or a mobile application. Message handler 705 may be a software and/or hardware module that handles messaging between web client 704 and web service 706 of server device 702. Message handler 705 may be, for example, an HTTP message handler (e.g., of HttpMessageHandler class) on the NET Framework developed by MICROSOFT CORPORATION of Redmond, Wash. Message handler 705 may be capable of performing the exponential moving average (EMA) function as well as storing and recalling EMA values. Web client 704 may use message handler 705 to invoke the make request (e.g., make HTTP request) function to send out a web request to web service 706. In response, message handler may use the EMA function to determine whether or not to throttle the web request. After message handler 705 sends out the web request (e.g., an HTTP request) to web service 706, message handler 705 may receive a web response (e.g., an HTTP response) from web service 706. Based on a timer that was initiated when the web request was sent out, message handler 705 may determine a response time for the web response. The response time may be recorded and an updated EMA value may be determined based on the response time. Message handler 705 may forward an external service response code (e.g., 200 OK, 400 Bad Request, 404 Not Found, etc.) to web client 704. If no response is received by message handler 705 before the timer expires, message handler 705 may return an error code (e.g., 408 Request Timeout) to web client 704.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Rowe et al. into the combination of Handa et al. and Holm et al. and Tribble et al. in order to better manage web requests and responses to improve user experience when the network condition deteriorates (See Rowe et al. ¶ [0003]).
As to claim 11, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the system according to claim 8 above. However, it does not expressly teach the details of wherein, to determine, based at least on the resource identifier, that an error prevents forwarding of the client request to the on-premises resource, the program code is structured to cause the processor to perform at least one of: determine that the on-premises resource is unreachable; determine that resource identifier has expired; or determine that resource identifier is invalid.
Rowe et al., from analogous art, teaches wherein, to determine, based at least on the resource identifier, that an error prevents forwarding of the client request to the on-premises resource, the program code is structured to cause the processor to perform at least one of: determine that the on-premises resource is unreachable; determine that resource identifier has expired; or determine that resource identifier is invalid (See ¶ [0101], Teaches that Client device 701 may include web client 704 and message handler 705. One or more components of client device 701 may be implemented with hardware, software, or a combination of both. Web client 704 may be any instance of application that is capable of making web requests. Web client 704 may be an HTTP client. For example, web client 704 may be a web browser, an email client, a calendar application, a social media application, a digital map application, a productivity application, a messaging application, a communications application, a database application, an information retrieval application, a microapp, etc. Web client 704 may be a desktop application or a mobile application. Message handler 705 may be a software and/or hardware module that handles messaging between web client 704 and web service 706 of server device 702. Message handler 705 may be, for example, an HTTP message handler (e.g., of HttpMessageHandler class) on the NET Framework developed by MICROSOFT CORPORATION of Redmond, Wash. Message handler 705 may be capable of performing the exponential moving average (EMA) function as well as storing and recalling EMA values. Web client 704 may use message handler 705 to invoke the make request (e.g., make HTTP request) function to send out a web request to web service 706. In response, message handler may use the EMA function to determine whether or not to throttle the web request. After message handler 705 sends out the web request (e.g., an HTTP request) to web service 706, message handler 705 may receive a web response (e.g., an HTTP response) from web service 706. Based on a timer that was initiated when the web request was sent out, message handler 705 may determine a response time for the web response. The response time may be recorded and an updated EMA value may be determined based on the response time. Message handler 705 may forward an external service response code (e.g., 200 OK, 400 Bad Request, 404 Not Found, etc.) to web client 704. If no response is received by message handler 705 before the timer expires, message handler 705 may return an error code (e.g., 408 Request Timeout) to web client 704.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Rowe et al. into the combination of Handa et al. and Holm et al. and Tribble et al. in order to better manage web requests and responses to improve user experience when the network condition deteriorates (See Rowe et al. ¶ [0003]).
As to claim 12, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the system according to claim 8 above. However, it does not expressly teach the details of wherein the application layer request comprising error handling information comprises: a Hypertext Transfer Protocol Secure (HTTPS) or a Hypertext Transfer Protocol (HTTP) message containing at least one of: a hostname of the on-premises resource, the error message, or a correlation identifier.
Rowe et al., from analogous art, teaches wherein the application layer request comprising error handling information comprises: a Hypertext Transfer Protocol Secure (HTTPS) or a Hypertext Transfer Protocol (HTTP) message containing at least one of: a hostname of the on-premises resource, the error message, or a correlation identifier (See ¶ [0101], Teaches that Client device 701 may include web client 704 and message handler 705. One or more components of client device 701 may be implemented with hardware, software, or a combination of both. Web client 704 may be any instance of application that is capable of making web requests. Web client 704 may be an HTTP client. For example, web client 704 may be a web browser, an email client, a calendar application, a social media application, a digital map application, a productivity application, a messaging application, a communications application, a database application, an information retrieval application, a microapp, etc. Web client 704 may be a desktop application or a mobile application. Message handler 705 may be a software and/or hardware module that handles messaging between web client 704 and web service 706 of server device 702. Message handler 705 may be, for example, an HTTP message handler (e.g., of HttpMessageHandler class) on the NET Framework developed by MICROSOFT CORPORATION of Redmond, Wash. Message handler 705 may be capable of performing the exponential moving average (EMA) function as well as storing and recalling EMA values. Web client 704 may use message handler 705 to invoke the make request (e.g., make HTTP request) function to send out a web request to web service 706. In response, message handler may use the EMA function to determine whether or not to throttle the web request. After message handler 705 sends out the web request (e.g., an HTTP request) to web service 706, message handler 705 may receive a web response (e.g., an HTTP response) from web service 706. Based on a timer that was initiated when the web request was sent out, message handler 705 may determine a response time for the web response. The response time may be recorded and an updated EMA value may be determined based on the response time. Message handler 705 may forward an external service response code (e.g., 200 OK, 400 Bad Request, 404 Not Found, etc.) to web client 704. If no response is received by message handler 705 before the timer expires, message handler 705 may return an error code (e.g., 408 Request Timeout) to web client 704.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Rowe et al. into the combination of Handa et al. and Holm et al. and Tribble et al. in order to better manage web requests and responses to improve user experience when the network condition deteriorates (See Rowe et al. ¶ [0003]).
As to claim 18, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the computer-readable storage medium according to claim 15 above. However, it does not expressly teach the details of wherein, to determine, based at least on the resource identifier, that an error prevents forwarding of the client request to the on-premises resource, the instructions, when executed by the processor, cause the processor to perform at least one of: determine that the on-premises resource is unreachable; determine that the resource identifier has expired; or determine that the resource identifier is invalid.
Rowe et al., from analogous art, teaches wherein, to determine, based at least on the resource identifier, that an error prevents forwarding of the client request to the on-premises resource, the instructions, when executed by the processor, cause the processor to perform at least one of: determine that the on-premises resource is unreachable; determine that the resource identifier has expired; or determine that the resource identifier is invalid (See ¶ [0101], Teaches that Client device 701 may include web client 704 and message handler 705. One or more components of client device 701 may be implemented with hardware, software, or a combination of both. Web client 704 may be any instance of application that is capable of making web requests. Web client 704 may be an HTTP client. For example, web client 704 may be a web browser, an email client, a calendar application, a social media application, a digital map application, a productivity application, a messaging application, a communications application, a database application, an information retrieval application, a microapp, etc. Web client 704 may be a desktop application or a mobile application. Message handler 705 may be a software and/or hardware module that handles messaging between web client 704 and web service 706 of server device 702. Message handler 705 may be, for example, an HTTP message handler (e.g., of HttpMessageHandler class) on the NET Framework developed by MICROSOFT CORPORATION of Redmond, Wash. Message handler 705 may be capable of performing the exponential moving average (EMA) function as well as storing and recalling EMA values. Web client 704 may use message handler 705 to invoke the make request (e.g., make HTTP request) function to send out a web request to web service 706. In response, message handler may use the EMA function to determine whether or not to throttle the web request. After message handler 705 sends out the web request (e.g., an HTTP request) to web service 706, message handler 705 may receive a web response (e.g., an HTTP response) from web service 706. Based on a timer that was initiated when the web request was sent out, message handler 705 may determine a response time for the web response. The response time may be recorded and an updated EMA value may be determined based on the response time. Message handler 705 may forward an external service response code (e.g., 200 OK, 400 Bad Request, 404 Not Found, etc.) to web client 704. If no response is received by message handler 705 before the timer expires, message handler 705 may return an error code (e.g., 408 Request Timeout) to web client 704.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Rowe et al. into the combination of Handa et al. and Holm et al. and Tribble et al. in order to better manage web requests and responses to improve user experience when the network condition deteriorates (See Rowe et al. ¶ [0003]).
As to claim 19, the combination of Handa et al. and Holm et al. and Tribble et al. teaches the computer-readable storage medium according to claim 15 above. However, it does not expressly teach the details of wherein the application layer request comprising error handling information comprises: a Hypertext Transfer Protocol Secure (HTTPS) or a Hypertext Transfer Protocol (HTTP) message containing at least one of: a hostname of the on-premises resource, the error message, or a correlation identifier.
Rowe et al., from analogous art, teaches wherein the application layer request comprising error handling information comprises: a Hypertext Transfer Protocol Secure (HTTPS) or a Hypertext Transfer Protocol (HTTP) message containing at least one of: a hostname of the on-premises resource, the error message, or a correlation identifier (See ¶ [0101], Teaches that Client device 701 may include web client 704 and message handler 705. One or more components of client device 701 may be implemented with hardware, software, or a combination of both. Web client 704 may be any instance of application that is capable of making web requests. Web client 704 may be an HTTP client. For example, web client 704 may be a web browser, an email client, a calendar application, a social media application, a digital map application, a productivity application, a messaging application, a communications application, a database application, an information retrieval application, a microapp, etc. Web client 704 may be a desktop application or a mobile application. Message handler 705 may be a software and/or hardware module that handles messaging between web client 704 and web service 706 of server device 702. Message handler 705 may be, for example, an HTTP message handler (e.g., of HttpMessageHandler class) on the NET Framework developed by MICROSOFT CORPORATION of Redmond, Wash. Message handler 705 may be capable of performing the exponential moving average (EMA) function as well as storing and recalling EMA values. Web client 704 may use message handler 705 to invoke the make request (e.g., make HTTP request) function to send out a web request to web service 706. In response, message handler may use the EMA function to determine whether or not to throttle the web request. After message handler 705 sends out the web request (e.g., an HTTP request) to web service 706, message handler 705 may receive a web response (e.g., an HTTP response) from web service 706. Based on a timer that was initiated when the web request was sent out, message handler 705 may determine a response time for the web response. The response time may be recorded and an updated EMA value may be determined based on the response time. Message handler 705 may forward an external service response code (e.g., 200 OK, 400 Bad Request, 404 Not Found, etc.) to web client 704. If no response is received by message handler 705 before the timer expires, message handler 705 may return an error code (e.g., 408 Request Timeout) to web client 704.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Rowe et al. into the combination of Handa et al. and Holm et al. and Tribble et al. in order to better manage web requests and responses to improve user experience when the network condition deteriorates (See Rowe et al. ¶ [0003]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
SHULMAN et al. (US 20170093824 A1) teaches Techniques related to virtual encryption patching are described. A security gateway includes multiple Transport Layer Security Implementations (TLSI) that can be used for creating secure communications channels to carry application-layer traffic between one or more clients and one or more server applications. In some embodiments, upon determining that one of the multiple TLSIs contains a security vulnerability, that TLSI can be disabled, leaving one or more others of the multiple TLSIs enabled and available to be used to carry traffic of new connections between the clients and server applications.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to James R Hollister whose telephone number is (571)270-3152. The examiner can normally be reached Mon - Fri 7:30 am - 4:00 pm.
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, Philip Chea can be reached at (571) 272-3951. 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.
James Hollister
/J.R.H./Examiner, Art Unit 2499 12/31/25
/PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499