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 the Claims
Claims 1-20 are presented for examination. Examiner has established objections for claims 10-11 and 13-14; and § 101 rejection for claims 1-20.
Claim Objections
Claim 10 is objected to because of the following informality:
10. The non-transitory machine-readable medium of claim 9, wherein the operations further comprise configuring the second type of web servers to provide an alternative form of payment excluding the processing the credit card payment.
There should be a colon (“:”) after the word “comprise.” Applicant could amend claim 10 to recite:
10. The non-transitory machine-readable medium of claim 9, wherein the operations further comprise:
configuring the second type of web servers to provide an alternative form of payment excluding the processing the credit card payment.
Claim 11 is objected to because of the following informality:
11. The non-transitory machine-readable medium of claim 8, wherein the determining routing of the incoming request further comprises determining the routing of the incoming request based on cryptographic cipher suites parameters and the detected TLS protocol version.
There should be a colon (“:”) after the word “comprises.” Applicant could amend claim 11 to recite:
11. The non-transitory machine-readable medium of claim 8, wherein the determining routing of the incoming request further comprises:
determining the routing of the incoming request based on cryptographic cipher suites parameters and the detected TLS protocol version.
Claim 13 is objected to because of the following informality:
13. The non-transitory machine-readable medium of claim 12, wherein the applying the AI/ML techniques further comprises applying K-Nearest neighbor algorithm.
There should be no words that have a capitalized first letters in the middle of the claim language; and there should be a colon (“:”) after the word “comprises.” Applicant could amend claim 13 to recite:
13. The non-transitory machine-readable medium of claim 12, wherein the applying the AI/ML techniques further comprises:
applying k-nearest neighbor algorithm.
Claim 14 is objected to because of the following informality:
14. The non-transitory machine-readable medium of claim 12, wherein the applying the AI/ML techniques further comprises applying the AI/ML techniques to perform anomaly detection, AI/ML assisted cipher threat hunting, coordination and reporting, automation of repetitive manual tasks, or a combination thereof.
There should be a colon (“:”) after the word “comprises.” Applicant could amend claim 14 to recite:
14. The non-transitory machine-readable medium of claim 12, wherein the applying the AI/ML techniques further comprises:
applying the AI/ML techniques to perform anomaly detection, AI/ML assisted cipher threat hunting, coordination and reporting, automation of repetitive manual tasks, or a combination thereof.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 USC § 101 because they are directed to non-statutory subject matter. The rationale for this finding is explained below.
The Supreme Court in Mayo laid out a framework for determining whether an applicant is seeking to patent a judicial exception itself or a patent-eligible application of the judicial exception. See Alice Corp., 134 S. Ct. at 2355,110 USPQ2d at 1981 (citing Mayo, 566 U.S. 66, 101 USPQ2d 1961). This framework, which is referred to as the Mayo test or the Alice/Mayo test (“the test”), is described in detail in Manual of Patent Examining Procedure (”MPEP”) (see MPEP § 2106(III) for further guidance). The step 1 of the test: It need to be determined whether the claims are directed to a patent eligible (i.e., statutory) subject matter under 35 USC § 101. Step 2A of the test: If the claims are found to be directed to a statutory subject matter, the next step is to determine whether the claims are directed to a judicial exception i.e., law of nature, natural phenomenon, and abstract idea (Prong 1). If the claims are found to be directed to an abstract idea, it needs to be determined whether the claims recite additional elements that integrate the judicial exception into a practical application (Prong 2). Step 2B of the test: If the claims are directed to a judicial exception, the next and final step is to determine whether the claims recite additional elements that amount to significantly more than the judicial exception.
Step 1 of the Test:
When considering subject matter eligibility under 35 USC § 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. Here, the claimed invention of claims 1-7 is a system, and, thus, one of the statutory categories of invention. Further, the claimed invention of claims 8-14 is a non-transitory machine-readable medium, which is also one of the statutory categories of invention. Still further, the claimed invention of claims 15-20 is a series of steps, which is method (i.e., a process), which is also one of the statutory categories of invention.
Conclusion of Step 1 Analysis: Therefore, claims 1-20 are statutory under 35 USC § 101 in view of step 1 of the test.
Step 2A of the Test:
Prong 1: Claims 1-20, however, recite an abstract idea of facilitating connection of browsers having different transport layer security versions using reverse proxy server. The abstract idea, as recited in the independent claims 1, 8, and 15, belongs to certain methods of organizing human activity (i.e., fundamental economic principles or practices including mitigating risk) that are found by the courts to be abstract ideas. The limitations in independent claims 1, 8, and 15, which set forth or describe the recited abstract idea, are found in the following steps:
“detecting the first version of the TLS protocol from the first web request” (claim 1);
“detecting the second version of the TLS protocol from the second web request” (claim 1);
“routing the first web request” (claim 1);
“routing the second web request” (claim 1);
“detecting a TLS protocol version used in the incoming request” (claim 8);
“determining routing of the incoming request at least based on the detected TLS protocol version” (claim 8);
“detecting a TLS protocol version and cryptographic cipher suites used in the incoming request” (claim 15); and
“determining routing of the incoming request to one of the first type of web servers and the second type of web servers at least based on the detected TLS protocol version and cryptographic cipher suites” (claim 15).
Prong 2: In addition to abstract steps recited above in Prong 1, independent claims 1, 8, and 15, recite additional elements:
“a processing system including a processor” (claim 1);
“a memory that stores executable instructions that, when executed by the processing system, facilitate performance of operations” (claim 1);
“a first browser of a first client machine, wherein the first browser uses a first version of a transport layer security (TLS) protocol” (claim 1);
“a second browser of a second client machine, wherein the second browser uses a second version of the TLS protocol” (claim 1);
“a first web server that is compliant with a current version of payment card industry data security standard (PCI DSS)” (claim 1);
“a second web server that is lacking a predetermined function of the first web server” (claim 1);
“a non-transitory machine-readable medium, comprising executable instructions that, when executed by a processing system including a processor, facilitate performance of operations” (claim 8);
“deploying a reverse proxy server in front of a first type of web servers and a second type of web servers, wherein the first type of web servers is compliant with a current version of payment card industry data security standard (PCI DSS) and supports a first version of a transport layer security (TLS) protocol, and wherein the second type of web servers supports one or more TLS protocols that are older than the first version of TLS protocol” (claim 8);
“a browser of a client machine” (claims 8 and 15);
“a router” (claims 8 and 15); and
“deploying, by a processing system including a processor, a reverse proxy server in front of a first type of web servers and a second type of web servers, wherein the first type of web servers is compliant with a current version of payment card industry data security standard (PCI DSS) and supports a first version of a transport layer security (TLS) protocol, and wherein the second type of web servers supports one or more TLS protocols that are older than the first version of TLS protocol and different cryptographic cipher suites” (claim 15).
These additional elements are recited at a high level of generality (e.g., as a generic processor performing a generic computer functions) such that they amount to no more than mere instructions to apply the exception using a generic computer components. Further, the following limitations recite insignificant extra solution activity (for example, data gathering):
“receiving a first web request” (claim 1);
“receiving a second web request” (claim 1);
“receiving an incoming request” (claims 8 and 15); and
“transmitting the determination to route the incoming request” (claims 8 and 15).
These additional limitations do not integrate the abstract idea into a practical application because they do not impose a meaningful limit on the judicial exception. The additional elements/limitations of independent claims 1, 8, and 15, here do not render improvements to the functioning of a computer or to any other technology or technical field (see MPEP § 2106.05(a)), nor do they integrate the abstract idea into a practical application under MPEP § 2106.05(b) (particular machine); MPEP § 2106.05(c) (particular transformations); or MPEP § 2106.05(e) (other meaningful limitations). Further, the combination of these additional elements/limitations is no more than mere instructions to apply the exception using a generic device. Accordingly, even in combination, these additional elements/ limitations do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Conclusion of Step 2A Analysis: Therefore, independent claims 1, 8, and 15, are non-statutory under 35 USC § 101 in view of step 2A of the test.
Step 2B of the Test: The additional elements of independent claims 1, 8, and 15, (see above under Step 2A - Prong 2) are described by Applicant’s Specification in following terms:
[0073] Generally, program modules comprise routines, programs, components, data structures, etc., that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the methods can be practiced with other computer system configurations, comprising single-processor or multiprocessor computer systems, minicomputers, mainframe computers, as well as personal computers, hand-held computing devices, microprocessor-based or programmable consumer electronics, and the like, each of which can be operatively coupled to one or more associated devices.
[0074] As used herein, a processing circuit includes one or more processors as well as other application specific circuits such as an application specific integrated circuit, digital logic circuit, state machine, programmable gate array or other circuit that processes input signals or data and that produces output signals or data in response thereto. It should be noted that while any functions and features described herein in association with the operation of a processor could likewise be performed by a processing circuit.
[0080] With reference again to FIG. 4, the example environment can comprise a computer 402, the computer 402 comprising a processing unit 404, a system memory 406 and a system bus 408. The system bus 408 couples system components including, but not limited to, the system memory 406 to the processing unit 404. The processing unit 404 can be any of various commercially available processors. Dual microprocessors and other multiprocessor architectures can also be employed as the processing unit 404.
[0119] As employed herein, the term “processor” can refer to substantially any computing processing unit or device comprising, but not limited to comprising, single-core processors; single-processors with software multithread execution capability; multi-core processors; multi-core processors with software multithread execution capability; multi-core processors with hardware multithread technology; parallel platforms; and parallel platforms with distributed shared memory. Additionally, a processor can refer to an integrated circuit, an application specific integrated circuit (ASIC), a digital signal processor (DSP), a field programmable gate array (FPGA), a programmable logic controller (PLC), a complex programmable logic device (CPLD), a discrete gate or transistor logic, discrete hardware components or any combination thereof designed to perform the functions described herein. Processors can exploit nano-scale architectures such as, but not limited to, molecular and quantum-dot based transistors, switches and gates, in order to optimize space usage or enhance performance of user equipment. A processor can also be implemented as a combination of computing processing units.
This is a description of general-purpose computing system. Thus, individually, the additional elements of independent claims 1, 8, and 15, are well-understood, routine, and conventional elements that amount to no more than implementing the abstract idea with a computerized system. Further, the additional limitations of “receiving” and “transmitting” information amount to no more than mere instructions to apply the exception using generic computer components. For the same reason these additional limitations are not sufficient to provide an inventive concept. The additional limitations of “receiving” and “transmitting” information were considered as insignificant extra-solution activity in Step 2A - Prong 2. Re-evaluating here in Step 2B, they are also determined to be well-understood, routine, and conventional activity in the field. Similarly to OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network), and buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and transmits information over a network), the additional limitations of independent claims 1, 8, and 15, “receive” and “transmit” information over a network in a merely generic manner. The courts have recognized “receiving” and “transmitting” information functions as well-understood, routine and conventional when claimed in a merely generic manner. Therefore, the additional limitations of independent claims 1, 8, and 15, are well-understood, routine, and conventional. Further, taken as combination, the additional elements/limitations add nothing more than what is present when the additional elements/limitations are considered individually. There is no indication that the combination provides any effect regarding the functioning of the computer or any improvement to another technology.
Conclusion of Step 2B Analysis: Therefore, independent claims 1, 8, and 15, are non-statutory under 35 USC § 101 in view of step 2B of the test.
Dependent Claims: Dependent claims 2-7 depend on independent claim 1; dependent claims 9-14 depend on independent claim 8; and dependent claims 16-20 depend on independent claim 15. The elements in dependent claims 2-7, 9-14, and 16-20, which set forth or describe the abstract idea, are:
“the second web server is configured to communicate with web requests using one or more versions of the TLS protocol that are non-compliant with the current version of PCI DSS” (claim 2: further narrowing the recited abstract idea);
“the current version of PCI DSS includes PCI DSS version 4.0 and the first version of the TLS protocol includes TLS version 1.3; and wherein the routing the second web request further comprises routing, to the second web server, the second web request using TLS version 1.2 or older, wherein TLS version 1.2 is compliant with PCI DSS version 4.0 and the second web request uses a cryptographical cipher suite that is not supported in TLS version 1.3” (claim 3: further narrowing the recited abstract idea);
“the operations further comprise arranging a reverse proxy server between the first and the second client machines and the first and the second web servers” (claim 4: further narrowing the recited abstract idea);
“the operations further comprise configuring the reverse proxy server to: detect a version of the TLS protocol from an incoming web request; and determine to route the incoming web request to the first web server or the second web server at least based on the version of the TLS protocol” (claim 5: further narrowing the recited abstract idea);
“the operations further comprise configuring the reverse proxy server to: detect that the version of the TLS protocol is not a particular version of the TLS protocol; and convert the detected version of the TLS protocol to the particular version of the TLS protocol” (claim 6: further narrowing the recited abstract idea);
“the predetermined function of the first web server comprises a credit card payment function, and wherein the operations further comprise providing a response including an alternative payment method excluding the credit card payment function from the second web server to the second client machine” (claim 7: further narrowing the recited abstract idea);
“configuring the first type of web servers to provide a full set of functionalities including processing a credit card payment” (claim 9: further narrowing the recited abstract idea);
“configuring the second type of web servers to provide an alternative form of payment excluding the processing the credit card payment” (claim 10: further narrowing the recited abstract idea);
“determining the routing of the incoming request based on cryptographic cipher suites parameters and the detected TLS protocol version” (claim 11: further narrowing the recited abstract idea);
“receiving application program interface (API) calls and audit logs of the first type of web servers at a center location; and applying artificial intelligence/machine learning (AI/ML) techniques to the API calls and the audit logs for detecting threat and data breach” (claim 12: where “receiving” step is insignificant extra solution activity; and “applying” step is further narrowing the recited abstract idea);
“the applying the AI/ML techniques further comprises applying k-nearest neighbor algorithm” (claim 13: further narrowing the recited abstract idea);
“applying the AI/ML techniques to perform anomaly detection, AI/ML assisted cipher threat hunting, coordination and reporting, automation of repetitive manual tasks, or a combination thereof” (claim 14: further narrowing the recited abstract idea);
“collecting, by the processing system, activity information from the first type of web servers; analyzing, by the processing system, the activity information with artificial intelligence/machine learning (AI/ML) techniques; and detecting, by the processing system, security threats based on the analysis with the AI/ML techniques” (claim 16: further narrowing the recited abstract idea, except “collecting” step is insignificant extra solution activity);
“receiving, by the processing system, a plurality of incoming requests from a plurality of browsers from a plurality of client machine; and configuring, by the processing system, the reverse proxy server, to bifurcate the plurality of incoming requests to the first type of web servers or the second type of web servers based on the TLS protocol version and cryptographic cipher suites used in each incoming request, wherein the configuring the reverse proxy server further includes configuring an access control list for the first type of web servers and the second type of web servers, respectively” (claim 17: further narrowing the recited abstract idea, except “receiving” step is insignificant extra solution activity);
“receiving, by the processing system, a plurality of incoming requests from a plurality of browsers from a plurality of client machine; and configuring, by the processing system, the reverse proxy server, to reduce PCI DSS destined traffic to be sent to the first type of web servers among the plurality of incoming requests” (claim 18: further narrowing the recited abstract idea, except “rreceiving” step is insignificant extra solution activity);
“applying, by the processing system, AI/ML techniques to the reduced PCI DSS destined traffic to detect data breaches, anomaly, cipher threat hunting, or a combination thereof” (claim 19: further narrowing the recited abstract idea); and
“redirecting, by the processing system, at least a part of the plurality of incoming requests to the second type of web servers, wherein the at least a part of the plurality of incoming requests utilize the one or more TLS protocols that are older than the first version of TLS protocol and support different cryptographic cipher suites, and wherein the one or more TLS protocols include a second version of TLS protocol that is compliant with the PCI DSS” (claim 20: further narrowing the recited abstract idea).
Conclusion of Dependent Claims Analysis: Dependent claims 2-7, 9-14, and 16-20, do not correct the deficiencies of independent claims 1, 8, and 15, and they are, thus, rejected on the same basis.
Conclusion of the 35 USC § 101 Analysis: Therefore, claims 1-20 are rejected as directed to an abstract idea without “significantly more” under 35 USC § 101.
Prior Art under 35 USC § 102 and § 103
Instant claims 1-20 recites a reverse proxy server that detects a version of a transport layer security (TSL) of a web request, and either routes the request to a server that is payment card industry data security standard (PCI DSS) compliant when the detected TSL version is up to the PCI DSS or routes the request to another server that is not PCI DSS compliant when the detected TSL version is not up to the PCI DSS.
Closest prior art reference – Miller (US 2009/0235067 A1) – teaches:
[A] connection for one or more incoming network requests on a port which recognizes encryption-related protocols may be accepted. Once the connection is accepted, load balancing may then be performed on the incoming network traffic requests. For encryption-related requests, the load balancing step may comprise sticky-session load balancing. After load balancing is performed, a server may be implicitly configured to respond to the incoming network requests without explicitly defining a plurality of SSL information for one or more web sites and without requiring a restart of the server. The implicitly configured server may then forward the incoming network traffic requests to one or more application servers.
Miller, thus, teaches forwarding the requests to different servers, but does so without taking the version of SSL (or TSL) into account.
Another close prior art reference – Yang (CN 117376448 A) – teaches:
[T]he server inquires the ssl/tls protocol version support mapping table according to the domain name requested by the client, and obtains the ssl/tls protocol version supported by the site corresponding to the domain name; and judging whether the ssl/tls protocol version in the client request is legal, if so, executing step e, otherwise, returning the abnormal information and ending the handshake process.
Young, therefore, teaches taking the version of SSL/TSL into account, but instead of forwarding requests including older versions of SSL/TSL, terminating the process.
Further, non-patent literature (NPL) reference – Debnath, Joyanta, Sze Yiu Chau, and Omar Chowdhury. "When tls meets proxy on mobile." International Conference on Applied Cryptography and Network Security. Cham: Springer International Publishing, 2020, (“Debnath”) – discloses:
Our evaluation shows that many proxy-based mobile browsers downgrade the overall quality of TLS sessions, by for example allowing old versions of TLS (e.g., SSLv3.0 and TLSv1.0) and accepting weak cryptographic algorithms (e.g., 3DES and RC4) as well as unsatisfactory certificates (e.g., revoked or signed by untrusted CAs), thus exposing their users to potential security and privacy threats.
Debnath teaches that many proxy-based browsers accept older versions of TSL and by doing so, expose their users to potential harm.
Miller, Yang, and Debnath, do not disclose – alone or in combination – the following limitations found in independent claims 1, 8, and 15, as an ordered combination of steps with other claim limitations:
Independent Claim 1:
routing the first web request to a first web server that is compliant with a current version of payment card industry data security standard (PCI DSS);
and
routing the second web request to a second web server that is lacking a predetermined function of the first web server.
Independent Claim 8:
deploying a reverse proxy server in front of a first type of web servers and a second type of web servers, wherein the first type of web servers is compliant with a current version of payment card industry data security standard (PCI DSS) and supports a first version of a transport layer security (TLS) protocol, and wherein the second type of web servers supports one or more TLS protocols that are older than the first version of TLS protocol;
and
determining, using the reverse proxy server, routing of the incoming request to one of the first type of web servers and the second type of web servers at least based on the detected TLS protocol version.
Independent Claim 15:
deploying, by a processing system including a processor, a reverse proxy server in front of a first type of web servers and a second type of web servers, wherein the first type of web servers is compliant with a current version of payment card industry data security standard (PCI DSS) and supports a first version of a transport layer security (TLS) protocol, and wherein the second type of web servers supports one or more TLS protocols that are older than the first version of TLS protocol and different cryptographic cipher suites;
and
configuring, by the processing system, the reverse proxy server to determine routing of the incoming request to one of the first type of web servers and the second type of web servers at least based on the detected TLS protocol version and cryptographic cipher suites.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Miller (US 8,886,937 B2) discloses:
[S]ystems and methods of the subject innovation can provide a Proxy Service that can adhere to Payment Card Industry Data Security Standard (PCI DSS) rules and regulations and can communicate with a Secure Socket Layer (SSL) encrypted electronic commerce (e-Commerce) Web Application on behalf of a Client Application. As used herein, SSL is intended to also encompass related protocols, such as Transport Layer Security. The Proxy Service can organize data received from the e-Commerce Web Application into a serialized data object. Any organized data that is disallowed for transport in this context, according to PCI DSS rules and regulations, can be encrypted with a cipher (e.g., 256-bit, etc.) before responding to the Client Application. The Client Application, which does not have the salt key, can relay the encrypted data back to the Proxy Service but cannot decrypt or make use of the encrypted data itself. The Proxy Service, which does have the original salt key, can decrypt and once again make use of the encrypted data.
Nanduri (EP 1869861 B1) discloses:
[0004] 1) Protocol version identification between web-browser and web-server. 2) Transmission of web-server's public key to the web-browser (the signed public key is also known as a Certificate). 3) Web-browser verifies the Certificate by communicating with a trusted entity (known as a Root Certificate Authority). This ensures that the web-browser is communicating with the intended web-server. 4) Negotiation and exchange of 'symmetric encryption-key' between web-browser and web-server. 5) The symmetric encryption-key is then used to establish an SSL or TLS 'channel' between the web-browser and web-server. 6) Encryption of all HTTP payload data between web-browser and web-server over the SSL/TLS channel.
[0005] It is imperative for SSL and TLS functionality to be implemented by the web-browser so that the SSL/TLS 'channel' is established directly from the web-browser. This guarantees the encryption and security of all HTTP data originating from the web-browser and received from the web-server. Reference is made to Figure 1 which depicts the aforementioned scenario.
D. Stebila and N. Sullivan, "An Analysis of TLS Handshake Proxying," 2015 IEEE Trustcom/BigDataSE/ISPA, Helsinki, Finland, 2015, pp. 279-286, discloses:
Content delivery networks (CDNs) are an essential component of modern website infrastructures: edge servers located closer to users cache content, increasing robustness and capacity while decreasing latency. However, this situation becomes complicated for HTTPS content that is to be delivered using the Transport Layer Security (TLS) protocol: the edge server must be able to carry out TLS handshakes for the cached domain. Most commercial CDNs require that the domain owner give their certificate's private key to the CDN's edge server or abandon caching of HTTPS content entirely.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VIRPI H. KANERVO whose telephone number is 571-272-9818. The examiner can normally be reached on Monday - Friday, 10 am - 6 pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Abhishek Vyas can be reached on 571-270-1836. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/VIRPI H KANERVO/Primary Examiner, Art Unit 3691
Prosecution Insights