DETAILED ACTION
Response to Arguments
Applicant’s arguments, see pages 9-14, filed on 6/17/2025, with respect to the rejection(s) of claim(s) 1-2, 6-7, 10-11 and 15-16 under 35 USC 102(a) as being anticipated by Zhigang et al. CN 104780178 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Hartmann et al. US 20030061510.
In addition, a new ground of rejection under 35 USC 101 is issued for claim 19. This office action is non-final as this new ground of rejection was not necessitated by amendment.
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.
Claim 19 is rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because is directed to a computer program or computer program product. A computer program and/or product is not one of the four statutory categories of patent eligible subject matter.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 8, 10-11, 17 and 19-20 are rejected under 35 USC 103 as being unpatentable over Hartmann et al. US 20030061510 (hereinafter Hartmann ‘510) in view of Freier RFC 6101 (hereinafter RFC 6101).
As per claim 1, Hartmann ‘510 discloses a communications server apparatus for determination of an abstention attack associated with a user communications device, the communications server apparatus comprising: a processor; and a memory, the communications server apparatus being configured, under control of the processor (para 0046, “SSL application server”), to execute instructions in the memory to:
transmit handshake data (para 0017, “5. A call to SSL_HANDSHAKE( ) 96 or 98 to initiate the two way SSL handshake negotiation 130, 132 of the cryptographic parameters. Both a server program and the client programs with which it communicates must provide a certificate for an SSL handshake 130, 132 to succeed.”);
monitor, for a defined time duration, for a handshake response from the user communications device corresponding to the handshake data (para 0022, “SSL API developers anticipated a server might block on the call to SSL_HANDSHAKE( ) 96, and therefore supply a timeout setting 88.”; para 0047, “ If in step step 90, no entry is found for this client in the ADL, in step 92 the client is added to an outstanding negotiation list … If timeout period "N" is not exceeded before completion 132 of the handshake, the relevant client entry is deleted (or its count value M is decremented) from the outstanding negotiation list and steps 110-118 executed to request and receive data. If the timeout value "N" 88 expires before the two-way handshake 130, 132 is complete, then in step 102 the server increments a counter M and in step 106 adds this client's IP address to the ADL file if the counter exceeds a trigger value T.”);
determine, in response to a combination of an expiry of the defined time duration with no handshake response corresponding to the handshake data being received by the communications server apparatus, and the communications server apparatus determining a presence of an event that is indicative of the user communications device being in a communication mode with the communications server apparatus, that there is an abstention attack (para 0039, “3. Numeric count threshold to trigger denial of service (how many timeouts before a client has its requests ignored)”; para 0047, “If the timeout value "N" 88 expires before the two-way handshake 130, 132 is complete, then in step 102 the server increments a counter M and in step 106 adds this client's IP address to the ADL file if the counter exceeds a trigger value T.”),
the event being at least one of (i) an indication that the user communications device is in a state of communication with the communications server apparatus, and (ii) an indication that the user communications device is in an active connection with the communications server apparatus (para 0046, “In this embodiment, in step 75 the SSL application server checks a cache copy of the ADL each time a client connects (step 86). If the client is found in the cache copy of the ADL, in step 77 a server copy of the ADL is accessed to refresh the cache copy” para 0047, “The counter will not deny service to a client until it exceeds some configurable threshold or "trigger" value "T”); and
generate, in response to the determination of the abstention attack, termination data to deny the user communications device access to the one or more first associated with the communications server apparatus (para 0043, “SSL handshake timeout setting 88 may be considered "smart" in that it is dynamically recalculated, using a weighting formula to account for network delays, for each client IP address that connects to the server. Thus, when any SSL client exceeds the smart timeout value, a counter is incremented to reflect this condition. When the tracking counter exceeds a trigger threshold, that client gets added to a denial of service, or access denied list (ADL). When any client is in the ADL, the SSL application server immediately closes any connection from that client and will not attempt to process it.”; para 0047, “if the client appears more than T times (or a counter value M for that client has been incremented to a value greater than T), the request is denied (steps 120, 124).”).
Hartmann ‘510 does not expressly disclose but RFC 6101 discloses the handshake data comprises a nonce (section 5.5, Handshake Protocol Overview, “The client hello and server hello establish the following attributes: Protocol Version, Session ID, Cipher Suite, and Compression Method. Additionally, two random values are generated and exchanged: ClientHello.random and ServerHello.random.… If the server has sent a certificate request message, the client must send either the certificate message or a no_certificate alert.”; section 5.6.3, Sever Key Exchange Message, “Signature.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hartmann ‘510 so that the handshake data comprises a nonce. One would have been motivated to do so to enable mutual authentication and/or to ensure that the client and server are able to establish a secure communication.
As per claim 2, Hartmann ‘510 in view of RFC 6101 disclose the communications server apparatus as claimed in claim 1 (supra). In addition, Hartmann ‘510 in view of RFC 6101 discloses wherein, for determining that there is the abstention attack, the communications server apparatus is configured to determine that there is the abstention attack in response to the expiry of the defined time duration with no handshake response (Hartmann ‘510, para 0043, “SSL handshake timeout setting 88 may be considered "smart" in that it is dynamically recalculated, using a weighting formula to account for network delays, for each client IP address that connects to the server. Thus, when any SSL client exceeds the smart timeout value, a counter is incremented to reflect this condition. When the tracking counter exceeds a trigger threshold, that client gets added to a denial of service, or access denied list (ADL).) comprising verification data being received by the communications server apparatus (RFC 6101, section 5.5 Handshake Protocol Overview, “If the server has sent a certificate request message, the client must send either the certificate message or a no_certificate alert. The client key exchange message is now sent, and the content of that message will depend on the public key algorithm selected between the client hello and the server hello. If the client has sent a certificate with signing ability, a digitally-signed certificate verify message is sent to explicitly verify the certificate.”; section F.1.1, Authentication and Key Exchange, “SSL supports three authentication modes: authentication of both parties.”), and, further, in response to the communications server apparatus determining the presence of the event (Hartmann ‘510, para 0039, “3. Numeric count threshold to trigger denial of service (how many timeouts before a client has its requests ignored)”; para 0047, “If the timeout value "N" 88 expires before the two-way handshake 130, 132 is complete, then in step 102 the server increments a counter M and in step 106 adds this client's IP address to the ADL file if the counter exceeds a trigger value T.”).
As per claim 8, Hartmann ‘510 in view of RFC 6101 disclose the communications server apparatus as claimed in claim1 (supra). In addition, Hartman ‘510 discloses wherein in response to the handshake response being received by the communications server apparatus within the defined time duration, the communications server apparatus is further configured to generate access data to allow the user communications device access to the service associated with the communications server apparatus (para 0047, “Otherwise, processing continues to step 96 to conduct the two-way handshake 130, 132 with an initial timeout value of "N". If timeout period "N" is not exceeded before completion 132 of the handshake, the relevant client entry is deleted (or its count value M is decremented) from the outstanding negotiation list and steps 110-118 executed to request and receive data. If the timeout value "N" 88 expires before the two-way handshake 130, 132 is complete, then in step 102 the server increments a counter M and in step 106 adds this client's IP address to the ADL file if the counter exceeds a trigger value T. The counter will not deny service to a client until it exceeds some configurable threshold or "trigger" value "T"”; completion of SSL handshake establishes a secure tunnel).
Claims 10-11 and 17 are method claims that correspond to claims 1-2 and 8. Therefore, claims 10-11 and 17 are rejected as being unpatentable over Hartmann ‘510 in view of RFC 6101 for the same reasons as claims 1-2 and 8.
Claims 19-20 are computer program and storage medium claims that correspond to claim 1. Therefore, claims 10-11 and 17 are rejected as being unpatentable over Hartmann ‘510 in view of RFC 6101 for the same reasons as claim 1.
Claims 3 and 12 are rejected under 103 as being unpatentable over Hartmann ‘510 in view of RFC 6101, and further in view of Underwood et al. WO 2011037536 (hereinafter Underwood ‘536).
As per claim 3, Hartmann ‘510 in view of RFC 6101 disclose the communications server apparatus as claimed in claim 1 (supra). Hartmann ‘640 further discloses dynamically setting the timeout value based on the expected RTT for a client (para 0047, “At this time, the average round trip timeout period "N" is also recalculated in step 102 for this client's IP address in order to set a smart value "N" (aka, RTT) for clients that have more delay in their network paths.”; para 0051, “Thus, the next time the client from this IP address connects, the server will set the handshake timeout value N based on the calculated timeout. N may be set at any value (2 as above, or more or less than 2) times RTT by the system administrator to allow for anticipated communication network delays.”)
Hartmann ‘510 does not expressly disclose wherein the defined time duration is between 2 minutes and 10 minutes. However, Underwood ‘536 discloses setting a timeout for an RTT to 10 minutes (page 8, lines 9-23, “Since the objective of the monitor is to identify anomalous Round Trip Times, as well as to monitor regular network performance, the timeout for the message to be returned from the RTT server should be set as long as possible given network communication constraints but no longer than the time between tests (i.e. no longer than predetermined period). To ensure "Lag" situations are captured a suitable timeout value would be 10 minutes. A 10 minute timeout period is long enough to capture a typical "lag event" where data transmission is interrupted for a period (for example due to cell congestion). A longer timeout is more likely to result in the user logging out of the device so that the sample is lost. The timeout value should be configurable from the RTT server, however, the timeout set by the RTT server may be overridden by the mobile device if it is longer than the current predetermined interval time (sampling interval). Should the timeout be reached then this data sample should be reported as the timeout time. For example, if the timeout is 10 minutes and no response is received in that time interval then the RTT report should show that sample as 10 minutes for the Round Trip Time.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hartmann ‘510 by setting the defined time duration between 2 minutes and 10 minutes. One would have been motivated to do so to account for known lag situations as disclosed by Underwood ‘536.
Claim 12 is a method claim that corresponds to claim 3. Therefore, claim 12 is rejected as being unpatentable over Hartmann ‘510 in view of RFC 6101 and Underwood ‘586 for the same reasons as claim 3.
Claims 4 and 13 are rejected under 103 as being unpatentable over Hartmann ‘510 in view of RFC 6101, and further in view of Hsueh et al. US 20120102553 (hereinafter Hsueh ‘553).
As per claim 4, Hartmann ‘510 in view of RFC 6101 disclose the communications server apparatus as claimed in claim 1 (supra). Hartmann ‘510 in view of RFC 6101 do not disclose, but Hsueh ‘553 discloses wherein, prior to transmitting the handshake data to the user communications device, the communications server apparatus is further configured to issue a session token to the user communications device (para 0028, “Tokens may be configured in a variety of ways. By way of example and not limitation, the term token as used herein may refer to encrypted cookies, encryption keys, digital certificates, binary large objects (BLOBs), a hash value, and/or other shared secrets or data that are suitable to make an authentication determination to determine whether a client 104, or other entity, "is who they say they are." In addition to being encrypted, tokens can be configured for use with particular protocols. For instance, insecure tokens may be configured for insecure communication protocols, such as HTTP. Likewise, secure tokens may be configured for corresponding secure communication protocols, such as SSL and/or HTTPS.”; para 0037, “A request for authentication and credentials are obtained (block 202). For example, a client 104 may seek authentication to obtain resources from a service provider 102. One way this may occur is by way of an authentication service 106. The client 104 may be redirected to the authentication service 106 when an attempt is made to access resources. At the authentication service 106, authentication manager 122 may cause a login interface to be output requesting input of credentials that may be input via the login interface by the client 104. The authentication manager 122 may then perform operations to authenticate the client 104.”; para 0041, “Based on this determination, the authentication manager 122 can selectively issue authentication tokens to the client. If secure mode is enabled, a secure token and an insecure token are issued to the client 104 (block 210). If secure mode is disabled, an insecure token is issued to the client 104 (block 212). For example, the secure token may be configured as an HTTPS cookie that is compatible with sites that use secure communications, such as secure sockets layer (SSL) or other secure protocols.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hartmann ‘510 in view of RFC 6101 such that a user is authenticated and issued a session token prior to transmitting the handshake data as taught by Hsueh ‘553. One would have been motivated to do so to provide a single-sign on capability for a plurality of resources, both unsecured and secured (e.g., via SSL), prior to the user attempting at access the resources. Such a configuration would improve user experience.
Claim 13 is a method claim that corresponds to claim 4. Therefore, claim 13 is rejected as being unpatentable over Hartmann ‘510 in view of RFC 6101 and Hsueh ‘553 for the same reasons as claim 4.
Claims 5 and 14 are rejected under 103 as being unpatentable over Hartmann ‘510 in view of RFC 6101, and Hsueh ‘553, and further in view of Schultz et al. US 20120054847 (hereinafter Schultz ‘847).
As per claim 5, Hartmann ‘510 in view of RFC 6101, and Hsueh ‘553 disclose the communications server apparatus as claimed in claim 4 (supra). Hartmann ‘510 in view of RFC 6101, and Hsueh ‘553 do not disclose, but Schultz ‘847 discloses wherein in response to the termination data generated, the communications server apparatus is further configured to invalidate the session token (para 0025-0026, “The trust application may detect a potential security event, associated with user device 110, when a level of trust is below a minimum threshold. Based on the detection of the potential security event, the trust application may deny access to user device 110. Additionally, or alternatively, the trust application may perform a containment operation that establishes a logical barrier to information flow, associated with user device 110, to and/or from service provider network 160. The trust application may perform the containment operation by sending a containment notification to SCP 120 indicating that the potential security event, associated with user device 110, has been detected. [0026] For example, the containment notification may include an instruction to deny access to user device 110, terminate a communication session associated with user device 110, invalidate a token issued to user device 110, etc.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to invalidate the session data in response to generating the termination data as taught by Schultz ‘847. One would have been motivated to do so to perform a containment operation that establishes a logical barrier to information flow associated with the user device and the security event in order to institute a more comprehensive security response.
Claim 14 is a method claim that corresponds to claim 5. Therefore, claim 14 is rejected as being unpatentable over Hartmann ‘510 in view of RFC 6101, Hsueh ‘553 and Schultz ‘847 for the same reasons as claim 5.
Claims 6-7, 9, 15-16 and 18 are rejected under 103 as being unpatentable over Hartmann ‘510 in view of RFC 6101, and Hsueh ‘553, and further in view of Roth et al. US 8996860 (hereinafter Roth ‘860).
As per claim 6, Hartmann ‘514 in view of RFC 6101 disclose the communications server apparatus of claim 1 (supra). Hartmann ‘510 in view of RFC 6101 does not disclose, but Hsueh ‘553 discloses wherein, prior to transmitting the handshake data to the user communications device, and in response to the communications server apparatus authenticating a user of the user communications device, the communications server apparatus is further configured to: generate data to identify presence of the user; (para 0041, “Based on this determination, the authentication manager 122 can selectively issue authentication tokens to the client. If secure mode is enabled, a secure token and an insecure token are issued to the client 104 (block 210) … For example, the secure token may be configured as an HTTPS cookie that is compatible with sites that use secure communications, such as secure sockets layer (SSL) or other secure protocols.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hartmann ‘510 in view of RFC 6101 such that a user is authenticated and issued a session token prior to transmitting the handshake data as taught by Hsueh ‘553. One would have been motivated to do so to provide a single-sign on capability for a plurality of resources, both unsecured and secured (e.g., via SSL), prior to the user attempting to access the resources. Such a configuration would improve user experience.
Hartmann ‘510 in view of RFC 6101 and Hsueh ‘553 does not disclose, but Roth ‘860 discloses and store the data in one or more data stores in the communications server apparatus (col. 3, lines 17-37, “In at least some embodiments, the application server 120 will provide the session identifier with other information in the form of a cookie or other secure token. A copy of the session identifier and other cookie information 124 can be stored locally, such as in a security data store 122 or other such location. A copy 112 of the cookie can also be sent across the network to be stored on the client device 102, whether in local storage 112, memory, the browser application, or another appropriate location. When the client device submits a subsequent request on that session, the request can be received to the application server 120 (or another, associated application server of the environment 106). The application server (or another appropriate component) can ensure that a copy of the cookie was included with the request, and can compare the information in the received copy of the cookie with the cookie information 124 stored locally. If the information, such as the session identifier and a key value, match the information stored locally, the request can be processed.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention such that the generated data to identify user presence is stored in the communications server as taught by Roth ‘860. One would have been motivated to do so to rely on a reference value stored in trusted location (the server) to verify a user’s token for a more secure verification scheme.
As per claim 7, Hartmann ‘510 in view of RFC 6101, Hsueh ‘553 and Roth ‘860 disclose the communications server apparatus of claim 6 (supra). Furthermore, Roth ‘860 discloses wherein the data comprises time data indicative of the time of identification of the presence of the user (col. 2, lines 2-4, “Each cookie can include information such as a time of issuance and an operation count, in addition to a session identifier or other such information.”; col. 4, lines 8-15, “An example of a cookie format includes the current time stamp signed under the session key, along with the identifier for the session. When the server (or a related server) receives such a cookie, the server can look up a session corresponding to the identifier and can validate information in the cookie, such as a timestamp matching a timestamp issued by the server for this session.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention such that the stored data comprises time of identification of the presence of the user. One would have been motivated to do so to rely on an additional reference check value (last time of user verification) in order to strengthen the verification process.
As per claim 9, Hartmann ‘510 in view of RFC 6101 disclose the communications server apparatus of claim 8 (supra). In addition, Hartmann ‘510 discloses (para 0047, “Otherwise, processing continues to step 96 to conduct the two-way handshake 130, 132 with an initial timeout value of "N". If timeout period "N" is not exceeded before completion 132 of the handshake, the relevant client entry is deleted (or its count value M is decremented) from the outstanding negotiation list and steps 110-118 executed to request and receive data. If the timeout value "N" 88 expires before the two-way handshake 130, 132 is complete, then in step 102 the server increments a counter M and in step 106 adds this client's IP address to the ADL file if the counter exceeds a trigger value T. The counter will not deny service to a client until it exceeds some configurable threshold or "trigger" value "T"”; completion of SSL handshake establishes a secure tunnel).
Hartmann ‘510 in view of RFC 6101 does not disclose, but Hsueh ‘553 discloses wherein, prior to transmitting the handshake data to the user communications device, and in response to the communications server apparatus authenticating a user of the user communications device, the communications server apparatus is further configured to: generate data to identify presence of the user (para 0041, “Based on this determination, the authentication manager 122 can selectively issue authentication tokens to the client. If secure mode is enabled, a secure token and an insecure token are issued to the client 104 (block 210) … For example, the secure token may be configured as an HTTPS cookie that is compatible with sites that use secure communications, such as secure sockets layer (SSL) or other secure protocols.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Hartmann ‘510 in view of RFC 6101 such that a user is authenticated and issued a session token prior to transmitting the handshake data as taught by Hsueh ‘553. One would have been motivated to do so to provide a single-sign on capability for a plurality of resources, both unsecured and secured (e.g., via SSL), prior to the user attempting to access the resources. Such a configuration would improve user experience.
Hartmann ‘510 in view of RFC 6101 and Hsueh ‘553 does not disclose, but Roth ‘860 discloses and store the data in one or more data stores in the communications server apparatus (col. 3, lines 17-37, “In at least some embodiments, the application server 120 will provide the session identifier with other information in the form of a cookie or other secure token. A copy of the session identifier and other cookie information 124 can be stored locally, such as in a security data store 122 or other such location. A copy 112 of the cookie can also be sent across the network to be stored on the client device 102, whether in local storage 112, memory, the browser application, or another appropriate location. When the client device submits a subsequent request on that session, the request can be received to the application server 120 (or another, associated application server of the environment 106). The application server (or another appropriate component) can ensure that a copy of the cookie was included with the request, and can compare the information in the received copy of the cookie with the cookie information 124 stored locally. If the information, such as the session identifier and a key value, match the information stored locally, the request can be processed.”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention such that the generated data to identify user presence is stored in the communications server as taught by Roth ‘860. One would have been motivated to do so to rely on a reference value stored in trusted location (the server) to verify a user’s token for a more secure verification scheme.
Claims 15-16 and 18 are method claims that correspond to claims 6-7 and 9. Therefore, claims 15-16 and 18 are rejected as being unpatentable over Hartmann ‘510 in view of RFC 6101, Hsueh ‘553 and Roth ‘860 for the same reasons as claim 6-7 and 9.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Penner et al. US 20200177630
Para [0116]: Referring now to operation (650), and in some embodiments, the subsequent handshake request 514 can be rejected. The first device 510 can determine to reject the first application request 514 responsive to identifying from the query that the first application request 514 has been recorded in the registry 512. For example, the first device 510 can reject the application request 514 and/or handshake request 514 as a replay attack. The subsequent handshake request 514, the application request 514 and/or data corresponding to the subsequent handshake request 514 being stored in at least one registry 512 or registry subset 512 can indicate that this subsequent handshake request 514 and/or application request 514 may correspond to a replay attack. Thus, the first device 510 can generate a response to the client device 510 indicating that the subsequent handshake request 514 and/or the application request 514 is denied or otherwise rejected.
Barnard et al. US 20180324260
Para [0039]: As previously noted, a number of sessions established for an account, for a user, and/or for a group of users may be limited. This provides those managing an account with an ability to set the maximum number of concurrent interactive sessions a user can have. The number (e.g., 1) may be set by an administrator and may vary from user to user and/or between roles of users.
Para [0044]: A second request 410 is received using the same credentials or using credentials that have been grouped into a group common with the credentials used for the first request 402. The second request 410 may be sent from a same electronic device 400 as the first request 402
Para [0051]: In such embodiments, this order reduces likelihood of closing of the session by unauthorized users, such as a denial of service attack.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUNG W KIM whose telephone number is (571)272-3804. The examiner can normally be reached Monday-Friday, 10 a.m. - 6 p.m..
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, Amy Cohen Johnson can be reached at 571-272-2238. 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.
/JUNG W KIM/Supervisory Patent Examiner, Art Unit 2494