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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 09/22/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant's arguments filed have been fully considered but they are not persuasive. The applicant argues that neither Penner et al. (US 2022/0232043), hereon referred to as Penner, nor Innes (US 2014/0331297), hereon referred to as Innes, alone or in combination does not teach/suggest all of the elements of the independent claim(s). The Applicant’s arguments require a definitive strict, and non-overlapping sequence of two TLS-related authentication processes. The applicant argues that prior requires strictly sequential, dependent authentication flows; and explicit linkage between the authentication steps and TLS-layer requests. The Applicant argues that Penner does not disclose performing a first series of authentication steps, making a connection-establishment determination based on completion of that series, and then performing a second authentication series tied to a second TLS request. The applicant also argues that Innes does not disclose sequential authentication; instead, applicant asserts it teaches only concurrent or parallel authentication and does not relate its authentication steps to TLS requests. Therefore, neither reference, alone or in combination teaches the required staged, dependent, multi-request authentication model.
However, the Examiner respectfully disagrees. The Applicant’s arguments read limitations into that are not explicit or definitively mentioned in the current claim language. The claims require only that the second authentication series occur “in response to completion” of the first, and not that it be architecturally restricted to a rigid, serialized chain. It is well known to an ordinary skill in the art that event-driven, scheduled, or ordinary sequential task execution satisfies this requirement. A “series of authentication steps” includes ordinary, multi-step operations inherent to TLS itself, such as certificate exchange, handshake messaging, certificate validation, and connection acceptance or rejection. Penner discloses of policy-based handling of TLS requests necessarily involves determining whether to establish a secure connection after authentication, which is an inherent feature of the TLS handshake. Therefore, Penner teaches to “determine whether to establish”. Additionally, a second TLS request in Penner initiates its own authentication sequence after the first has completed. This addresses the limitation of “in response to completion”. Innes teaches of multi-stage authentication involving proxy authentication, user/resource authentication, and certificate-based access. These teach/suggest of sequential execution. Additionally, authentication of certificates and entities for secure communication is well known to an ordinary skill in the art to be associated to TLS, even if not explicitly mentioned.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-10, 12-14, 18-20, 22-27, 30-32 are rejected under 35 U.S.C 103 as being unpatentable over Penner et al. (US 2022/0232043), hereon referred to as Penner, in view of Innes (US 2014/0331297), and hereon referred to as Innes.
In regards to claims 1, 18 & 30, Penner discloses receive, with a transport layer security stack of the computing device, a first transport layer security request from a first internal communication endpoint task and a second transport layer security request from a second internal communication endpoint task, wherein the first transport layer security request is related to establishing a secure connection with a first external communication endpoint and the second transport layer security request is related to establishing a secure connection with a second external communication endpoint (Load balancing of servers to process requests from clients, act as a proxy or access server to provide access to the one or more servers, provide security and/or act as a firewall between a client and a server; An application layer policy to a transport layer security request. A device intermediary to one or more client devices and one or more servers can selectively allow or disable early data request (e.g., transport layer security (TLS) requests) processing dynamically; The device can allow or reject early data requests for an application or resource provided by a server based in part on application layer policies generated for the particular application or resource provided by the server. The application layer policies can be generated to provide precise control of speed versus security tradeoffs for early data request processing based at least in part on polices applied to the respective requests; The client device can transmit a plurality of TLS requests to the device; A plurality of client devices can transmit a TLS request to the device; Receiving, by a device intermediary to one or more clients and one or more servers, a transport layer security (TLS) request to establish a TLS connection between a client device of the one or more clients and a server of the one or more servers; The TLS request can include an application layer request to a resource of the server; The TLS request can identify one or more servers of the plurality of servers to establish an application connection with a client device; Paragraphs 0028-0030; 0041-0045; 0070-0080; 0092-0095; Fig. 1-2); perform a first series of authentication steps with the computing device related to the first transport layer security request (The application layer request can include a HyperText Transfer Protocol (HTTP) request; The application layer request can identify at least one server (e.g., HTTP server) of the plurality of servers to establish an application connection; The application layer request can identify at least one resource hosted or provided by at least one server of the plurality of servers; The application layer request can include a pattern for matching against at least a portion of an application layer policy; The application layer request can include a pattern corresponding to a resource provided by at least one server of the plurality of servers; The application layer request can include an identifier, string, a URL, or a portion of URL corresponding to a resource provided by at least one server of the plurality of servers; Paragraphs 0070-0080; 0090-0096; Figs. 1-2).
However, Penner does not disclose determine whether to establish the secure connection between the first external communication endpoint and the computing device in response to completion of the first series of authentication steps; and perform a second series of authentication steps with the computing device related to the second transport layer security request, in response to completion of the first series of authentication steps. In an analogous art Innes discloses determine whether to establish the secure connection between the first external communication endpoint and the computing device in response to completion of the first series of authentication steps (After the authentication a secured connection sessions with the resource/sever(s) is established; Paragraphs 0123-0131); and perform a second series of authentication steps with the computing device related to the second transport layer security request, in response to completion of the first series of authentication steps (Different authentication protocols/services are utilized for different client devices/servers and requests; Paragraphs 0110-0115; 0123-0131; 0165).
At the time before the effective filing date of the invention, it would have been obvious to the one with ordinary skill in the art to combine the teachings disclosed by Penner, with the teachings disclosed by Innes regarding determine whether to establish the secure connection between the first external communication endpoint and the computing device in response to completion of the first series of authentication steps; and perform a second series of authentication steps with the computing device related to the second transport layer security request, in response to completion of the first series of authentication steps. The suggestion/motivation of the combination would have been to provide additional security for a client device to securely access resources using a proxy device (Innes; Paragraph 0001).
In regards to claim 2, the combination of Penner and Innes discloses instructions executable to prioritize memory resources with respect to performance of the first series of authentication steps over the second series of authentication steps, until the first series of authentication steps has been completed (The elements presented in the claim(s) do not contain any additional features, do not present any inventive step or novelty not addressed/presented in the combination of Penner and Innes. Examiner takes official notice, that these elements are commonly known, minor design details that are derivable from the prior art and are well known, and obvious to an ordinary skill in the art. The additional features of these claims represent normal design options, which the skilled person would implement the combination of Penner and Innes, depending on the circumstances, without exercising any inventive activity).
In regards to claim 3, Innes discloses wherein the instructions executable by the processor to complete the first series of authentication steps include instructions executable to determine, with the computing device, that credentials of the first external communication endpoint are trusted (The single-sign-on processes may allow a user to provide a single set of authentication credentials, which are then verified by an authentication service. The authentication service may then grant to the user access to multiple enterprise resources, without requiring the user to provide authentication credentials to each individual enterprise resource; Paragraph 0072).
In regards to claim 4, the combination of Penner and Innes discloses wherein the first internal communication endpoint task is located internally with respect to the computing device and forwards the first transport layer security request from the first external communication endpoint to the transport layer security stack (The elements presented in the claim(s) do not contain any additional features, do not present any inventive step or novelty not addressed/presented in the combination of Penner and Innes. Examiner takes official notice, that these elements are commonly known, minor design details that are derivable from the prior art and are well known, and obvious to an ordinary skill in the art. The additional features of these claims represent normal design options, which the skilled person would implement the combination of Penner and Innes, depending on the circumstances, without exercising any inventive activity).
In regards to claim 5, Innes discloses wherein the first internal communication endpoint is located internally with respect to the computing device and initiates a request to establish the secure connection with the first external communication endpoint ((After the authentication a secured connection sessions with the external resource/sever(s) is established; Paragraphs 0123-0131; Figs.4-7).
In regards to claim 6, the combination of Penner and Innes discloses instructions executable by the processor to receive the first transport layer security request and the second transport layer security request at a same time (The elements presented in the claim(s) do not contain any additional features, do not present any inventive step or novelty not addressed/presented in the combination of Penner and Innes. Examiner takes official notice, that these elements are commonly known, minor design details that are derivable from the prior art and are well known, and obvious to an ordinary skill in the art. The additional features of these claims represent normal design options, which the skilled person would implement the combination of Penner and Innes, depending on the circumstances, without exercising any inventive activity).
In regards to claim 7, Penner discloses prioritize the first transport layer security request over the second transport layer security request, based on a time stamp of when each one of the first transport layer security request and the second transport layer security request was received ((Load balancing of servers to process requests from clients, act as a proxy or access server to provide access to the one or more servers, provide security and/or act as a firewall between a client and a server; An application layer policy to a transport layer security request. A device intermediary to one or more client devices and one or more servers can selectively allow or disable early data request (e.g., transport layer security (TLS) requests) processing dynamically; The device can allow or reject early data requests for an application or resource provided by a server based in part on application layer policies generated for the particular application or resource provided by the server; Paragraphs 0070-0080; 0090-0096; Figs. 1-2).
In regards to claim 8, Innes discloses wherein the instructions executable to perform the first series of authentication steps with the computing device include instructions executable to utilize a handshake memory associated with the computing device to perform the first series of authentication steps (Authentication conversation between the proxy device and the resource prior to requesting the signature from the client device; all of the SSL operations (e.g., handshake messages) may be provided to the client device; The proxy device generates a cumulative digest of SSL operations performed; Paragraph 0140-0150).
In regards to claim 9, Innes discloses dedicate all of the handshake memory to performing the first series of authentication steps (Authentication conversation between the proxy device and the resource prior to requesting the signature from the client device; all of the SSL operations (e.g., handshake messages) may be provided to the client device; The proxy device generates a cumulative digest of SSL operations performed; Paragraph 0140-0150).
In regards to claim 10, Innes discloses instructions executable by the processor to release the handshake memory in response to completion of the first series of authentication steps (Authentication conversation between the proxy device and the resource prior to requesting the signature from the client device; all of the SSL operations (e.g., handshake messages) may be provided to the client device; The proxy device generates a cumulative digest of SSL operations performed; Paragraph 0140-0150).
In regards to claims 12, 18 & 24, Innes discloses further comprising instructions executable by the processor to: receive, with the computing device, a Hypertext Transfer Protocol (HTTP) request, from the first external communication endpoint, upon performing the first series of authentication steps, wherein the HTTP request includes a request to share static data with the first external communication endpoint; and parse the HTTP request with the handshake memory of the computing device and provide static data to the first external communication endpoint (Authentication conversation between the proxy device and the resource prior to requesting the signature from the client device; all of the SSL operations (e.g., handshake messages) may be provided to the client device; The proxy device generates a cumulative digest of SSL operations performed; the application on the server side may transmit back to the mobile device a new GUI. For example, the new GUI may be a static page, a dynamic page, an animation, or the like; The virtual private network connections may carry Microsoft Exchange traffic, Microsoft Active Directory traffic, HTTP traffic, HTTPS traffic, application management traffic, and the like; The proxy device 710 may translate between a first protocol to the resource (e.g., Kerberos or SSL) and a second, different protocol to the client device 705 (e.g., HTTP or HTTPS); Paragraphs 0069-0072; 0113; 0129-0136; 0140-0150).
In regards to claims 13 & 20, Innes discloses to release the handshake memory upon parsing the HTTP request and provide the static data to the first external communication endpoint (Authentication conversation between the proxy device and the resource prior to requesting the signature from the client device; all of the SSL operations (e.g., handshake messages) may be provided to the client device; The proxy device generates a cumulative digest of SSL operations performed; the application on the server side may transmit back to the mobile device a new GUI. For example, the new GUI may be a static page, a dynamic page, an animation, or the like; The virtual private network connections may carry Microsoft Exchange traffic, Microsoft Active Directory traffic, HTTP traffic, HTTPS traffic, application management traffic, and the like; The proxy device 710 may translate between a first protocol to the resource (e.g., Kerberos or SSL) and a second, different protocol to the client device 705 (e.g., HTTP or HTTPS); Paragraphs 0069-0072; 0113; 0129-0136; 0140-0150).
In regards to claims 14 & 22, Innes discloses to receive, with the computing device, a Hypertext Transfer Protocol (HTTP) request, from the first external communication endpoint, upon performing the first series of authentication steps, wherein the HTTP request includes a request to share dynamic data with the first external communication endpoint and a request to switch protocols for additional handling of dynamic data (Authentication conversation between the proxy device and the resource prior to requesting the signature from the client device; all of the SSL operations (e.g., handshake messages) may be provided to the client device; The proxy device generates a cumulative digest of SSL operations performed; the application on the server side may transmit back to the mobile device a new GUI. For example, the new GUI may be a static page, a dynamic page, an animation, or the like; The virtual private network connections may carry Microsoft Exchange traffic, Microsoft Active Directory traffic, HTTP traffic, HTTPS traffic, application management traffic, and the like; The proxy device 710 may translate between a first protocol to the resource (e.g., Kerberos or SSL) and a second, different protocol to the client device 705 (e.g., HTTP or HTTPS); Paragraphs 0069-0072; 0113; 0129-0136; 0140-0150).
In regards to claim 23, Innes discloses further including instructions executable by the processor to utilize all of the handshake memory to perform the first series of authentication steps (Authentication conversation between the proxy device and the resource prior to requesting the signature from the client device; all of the SSL operations (e.g., handshake messages) may be provided to the client device; The proxy device generates a cumulative digest of SSL operations performed; Paragraph 0140-0150).
In regards to claim 25, the combination of Penner and Innes discloses further including instructions executable by the processor to utilize all of the handshake memory to perform the second series of authentication steps, upon completion of the HTTP request being parsed (The elements presented in the claim(s) do not contain any additional features, do not present any inventive step or novelty not addressed/presented in the combination of Penner and Innes. Examiner takes official notice, that these elements are commonly known, minor design details that are derivable from the prior art and are well known, and obvious to an ordinary skill in the art. The additional features of these claims represent normal design options, which the skilled person would implement the combination of Penner and Innes, depending on the circumstances, without exercising any inventive activity).
In regards to claim 26, Innes discloses wherein the HTTP request includes a request to switch protocols and provide dynamic data (Authentication conversation between the proxy device and the resource prior to requesting the signature from the client device; all of the SSL operations (e.g., handshake messages) may be provided to the client device; The proxy device generates a cumulative digest of SSL operations performed; the application on the server side may transmit back to the mobile device a new GUI. For example, the new GUI may be a static page, a dynamic page, an animation, or the like; The virtual private network connections may carry Microsoft Exchange traffic, Microsoft Active Directory traffic, HTTP traffic, HTTPS traffic, application management traffic, and the like; The proxy device 710 may translate between a first protocol to the resource (e.g., Kerberos or SSL) and a second, different protocol to the client device 705 (e.g., HTTP or HTTPS); Paragraphs 0069-0072; 0113; 0129-0136; 0140-0150).
In regards to claim 27, Innes discloses provide dynamic data to the first external communication endpoint using a session memory; and receive a message from the first external communication endpoint to close the connection with the first external communication endpoint (Authentication conversation between the proxy device and the resource prior to requesting the signature from the client device; all of the SSL operations (e.g., handshake messages) may be provided to the client device; The proxy device generates a cumulative digest of SSL operations performed; the application on the server side may transmit back to the mobile device a new GUI. For example, the new GUI may be a static page, a dynamic page, an animation, or the like; The virtual private network connections may carry Microsoft Exchange traffic, Microsoft Active Directory traffic, HTTP traffic, HTTPS traffic, application management traffic, and the like; The proxy device 710 may translate between a first protocol to the resource (e.g., Kerberos or SSL) and a second, different protocol to the client device 705 (e.g., HTTP or HTTPS); Paragraphs 0069-0072; 0113; 0129-0136; 0140-0150).
In regards to claim 31 the combination of Penner and Innes discloses receiving a message from the first one of the plurality of external communication endpoints to close the secure connection between the transport layer security stack and the first one of the plurality of external communication endpoints; and performing the second series of authentication steps in response to the secure connection with the first one of the plurality of external communication endpoints being closed (The elements presented in the claim(s) do not contain any additional features, do not present any inventive step or novelty not addressed/presented in the combination of Penner and Innes. Examiner takes official notice, that these elements are commonly known, minor design details that are derivable from the prior art and are well known, and obvious to an ordinary skill in the art. The additional features of these claims represent normal design options, which the skilled person would implement the combination of Penner and Innes, depending on the circumstances, without exercising any inventive activity).
In regards to claim 32, Innes discloses utilizing all of the handshake memory in establishing the secure connection, parsing the HTTP request, and providing the static data to the first one of the plurality of external communication endpoints (Authentication conversation between the proxy device and the resource prior to requesting the signature from the client device; all of the SSL operations (e.g., handshake messages) may be provided to the client device; The proxy device generates a cumulative digest of SSL operations performed; the application on the server side may transmit back to the mobile device a new GUI. For example, the new GUI may be a static page, a dynamic page, an animation, or the like; The virtual private network connections may carry Microsoft Exchange traffic, Microsoft Active Directory traffic, HTTP traffic, HTTPS traffic, application management traffic, and the like; The proxy device 710 may translate between a first protocol to the resource (e.g., Kerberos or SSL) and a second, different protocol to the client device 705 (e.g., HTTP or HTTPS); Paragraphs 0069-0072; 0113; 0129-0136; 0140-0150).
Allowable Subject Matter
Claims 11, 15-17, 21 & 28-29 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHARIF E ULLAH whose telephone number is (571)272-5453. The examiner can normally be reached Mon-Fri 7:00-5:30.
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, Farid Homayounmehr can be reached at 571-272-3739. 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.
/SHARIF E ULLAH/Primary Examiner, Art Unit 2495