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 .
DETAILED ACTION
This action is in response to applicant’s original submittal made on 04/21/2025. Claims 1-20 are pending.
Examiner’s Note –
The examiner notes for the record that applicant’s recital of sub-code in dependent claims 13 and 14 have been interpreted as computer program code.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d).
Double Patenting
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory double patenting rejection is appropriate where the claims at issue are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a non-statutory double patenting ground provided the reference application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim 1, 10 and 12 are rejected on the ground of non-statutory double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,294,572 and 572’ hereinafter. Although the claims at issue are not identical, they are not patentably distinct from each other because both sets of claims are drawn to the following:
(19/184581) Claim 1… obtaining, in response to a key agreement request from a terminal device, key agreement data comprising a public key, the key agreement request including an identifier of a target user; transmitting, to the terminal device, the key agreement data, based on which encryption processing is performed at the terminal device on to-be-verified information for a target application by using the public key included in the key agreement data, to obtain to-be-verified ciphertext information, the to-be-verified information comprising user information corresponding to the target user; receiving the to-be-verified ciphertext information from the terminal device; performing decryption processing on the to-be-verified ciphertext information, to obtain a first information digest; matching the first information digest with a second information digest, to obtain an information verification result, the second information digest being a stored information digest; and transmitting the information verification result to the terminal device, the information verification result indicating a result of logging in to an application server by the terminal device, without providing the to-be-verified information to the application server, which is a server of the target application; maps to (572’) Claim 1 …obtaining, in response to a key agreement request from a terminal device, key agreement data comprising a public key and a first random number, the key agreement request including an identifier of a target user; transmitting, to the terminal device, the key agreement data, based on which, after an application login request to an application server is initiated by the terminal device and to-be-verified information is entered through the terminal device, encryption processing is performed at the terminal device on the to-be-verified information for a target application by using a second random number, the public key, and the first random number included in the key agreement data, to obtain to-be-verified ciphertext information, the to-be-verified information comprising user information corresponding to the target user, the application server being a server of the target application; receiving, either from the terminal device or from the application server, the to-be-verified ciphertext information; performing decryption processing on the to-be-verified ciphertext information, to obtain a first information digest; matching the first information digest with a second information digest, to obtain an information verification result, the second information digest being a stored information digest; and transmitting the information verification result to the terminal device, the information verification result indicating a result of logging in to the application server by the terminal device, without providing the to-be-verified information to the server of the target application.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 2, 5, 10-13, 16 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Ali (US Patent Publication No. 2006/0041938 (Cited from IDS 04/21/2025) in view of Yedidi et al. (UJS Patent Publication No. 2017/0346821 and Yedidi hereinafter).
As to claims 1 and 12, Ali teaches an information verification method, performed by a verification server, the information verification method comprising:
obtaining, in response to a key agreement request from a terminal device (i.e., …teaches in par. 0226 the following: “The client-key-exchange message 1005: The client sends the server this message to begin the process of session key exchange.” … teaches in par. 0056 the following: As a result of this handshake, a set of session keys is established, and a secure connection is created with the client.),
key agreement data comprising a public key (i.e., …teaches in par. 0226 the following: “the client random number (see message 1001), the server random number (see message 1002), and the pre-master-secret. …further teaches in par. 0226 the following: “The client-key-exchange message 1005: The client sends the server this message to begin the process of session key exchange. This message has a pre-master-secret that has been encrypted using the public key of the server. The server public key was sent in the certificate message 1003.” ..teaches in par. 00239 the following: “This public key was sent to the client in the server-hello message 1702”),
the key agreement request including an identifier of a target user (i.e., …teaches in par. 0222 the following: “This message includes the proposed protocol version, a list of cipher suites supported by the client, and a client random number that will be used in the key generation process.”);
transmitting, to the terminal device, the key agreement data (i.e., …teaches in par. 0226 the following: “the client random number (see message 1001), the server random number (see message 1002), and the pre-master-secret.”),
based on which encryption processing is performed at the terminal device on to-be-verified information for a target application by using the public key included in the key agreement data (i.e., …teaches in par. 0047 the following: “Protocol Module 701. This module determines the exact SSL/TLS protocol version being negotiated between the client and the server.” … teaches in par. 0222 the following: “The client-hello message 1001: The client side (e.g. remote TLS client 1010) initiates a TLS handshake by sending the server a client-hello message 1001. This message includes the proposed protocol version, a list of cipher suites supported by the client, and a client random number that will be used in the key generation process.” … teaches in par. 0226 the following: “the client random number (see message 1001), the server random number ……further teaches in par. 0226 the following: “the client random number (see message 1001), the server random number (see message 1002), and the pre-master-secret. …teaches in par. 0226 the following: “The client-key-exchange message 1005: The client sends the server this message to begin the process of session key exchange. This message has a pre-master-secret that has been encrypted using the public key of the server. The server public key was sent in the certificate message 1003.” ..teaches in par. 00239 the following: “This public key was sent to the client in the server-hello message 1702”..);
to obtain to-be-verified ciphertext information (i.e., …teaches in par. 00129 the following: “TLS 1.0 specification requires that both client and server maintain a digest (hashed MAC)”),
the to-be- verified information comprising user information corresponding to the target user (i.e., …teaches in par. 00129 the following: “TLS 1.0 specification requires that both client and server maintain a digest (hashed MAC)”);
receiving the to-be-verified ciphertext information from the terminal device (i.e., …teaches in par. 0140 the following: “The remote TLS client 1010 sends the client-finish message 1007 to the resource-constrained device. The TSH module 202 on the resource-constrained device receives this message (see FIG. 10). The client-finish message 1007 contains a MAC”);
performing decryption processing on the to-be-verified ciphertext information (i.e., …teaches in par. 0226 the following: “The server side decrypts”),
to obtain a first information digest (i.e., … teaches in par. 0140 the following: “The resulting value is then compared with the 12-byte value received in client-finish message 1007.” … teaches in par. 0226 the following: “the client random number (see message 1001), the server random number);
matching the first information digest with a second information digest, to obtain an information verification result (i.e., …teaches in par. 0140 the following: “The resulting value is then compared with the 12-byte value received in client-finish message 1007.” Teaches in par. 0148 the following: “This hash value is the intermediate digest value, which is used for comparing the corresponding value sent by the remote TLS client 10”.);
the second information digest being a stored information digest (i.e., teaches in par. 0148 the following: “This hash value is the intermediate digest value, which is used for comparing the corresponding value sent by the remote TLS client 10”. teaches in par. 0226 the following: “the client random number (see message 1001), the server random number),
and transmitting the information verification result to the terminal device (i.e., …teaches in par. 0056 the following: As a result of this handshake, a set of session keys is established, and a secure connection is created with the client. …teaches in par. 0230 the following: “sends a corresponding server-finish message to the client.”).
Ali does not expressly teach:
the information verification result indicating a result of logging in to an application server by the terminal device,
without providing the to-be-verified information to the application server,
which is a server of the target application.
In this instance the examiner notes the teachings of prior art reference Yedidi.
With regards to applicant’s claim limitation element of, “the information verification result indicating a result of logging in to an application server by the terminal device”, Yedidi teaches in par. 0058 the following: “login context database 204 (i.e., database 300) can store a database entry (e.g., record) that includes login context data collected for each attempt to log in to a user account managed by content management system 106.”.
With regards to applicant’s claim limitation element of, “without providing the to-be-verified information to the application server”, Yedidi teaches in par. 0051 the following: “When the anonymous proxy metric value (e.g., number of anonymous logins) exceeds a threshold number of anonymous logins,”. Teaches in par. 0059 the following: “content management system 106 can generate a login metric. For example, content management system 106 can generate one or more login metrics based on the login context data stored in login context database 204. The login metrics can include a login frequency metric, an IP addresses metric, a client location metric, a browser types metric, a native clients metric, a login sessions metric, an anonymous proxy metric, a number of devices metric, and/or other login metrics, as described above.”.
With regards to applicant’s claim limitation element of, “which is a server of the target application”, Yedidi teaches in par. 0059 the following: “content management system 106 can generate a login metric. For example, content management system 106 can generate one or more login metrics based on the login context data stored in login context database 204. The login metrics can include a login frequency metric, an IP addresses metric, a client location metric, a browser types metric, a native clients metric, a login sessions metric, an anonymous proxy metric, a number of devices metric, and/or other login metrics, as described above.”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the of the claimed invention was made to implement the teachings of Ali with the teachings of Yedidi by having their system comprise an enhanced access login recording process. One would have been motivated to do so to provide a simple and effective means to determine system intrusion, wherein the enhanced access login recording process helps facilitate access security within the network and makes it easier to provide access monitoring.
As to claim 2, the system of Ali and Yedidi as applied to claim 1 above teaches a digest verification process, specifically Ali teaches an information verification method according to claim 1, wherein the obtaining the key agreement data comprises: transmitting a ciphertext generation request to an encryptor (i.e. …teaches in par.0068 the following: “’ Crypto Module 206 supports various cryptographic algorithms that are used in the implementation of SSL/TLS protocols. Examples of these algorithms are: RSA for authentication and key exchange, DES and 3-DES for symmetric encryption, HMAC for hashed MAC, and MD-5 and SHA-1 for message digest.”);
receiving, from the encryptor, ciphertext data generated based on the ciphertext generation request (i.e., …teaches in par. 0151 the following: “The resulting record (i.e. concatenation of the data segment and its MAC) is encrypted using the session keys and algorithms established during the TLS handshake”),
the ciphertext data comprising the public key (i.e., …teaches in par. 0222 the following: “The client-hello message 1001: The client side (e.g. remote TLS client 1010) initiates a TLS handshake by sending the server a client-hello message 1001. This message includes the proposed protocol version, a list of cipher suites supported by the client, and a client random number that will be used in the key generation process.” …teaches in par. 0047 the following: “Protocol Module 701. This module determines the exact SSL/TLS protocol version being negotiated between the client and the server.” … teaches in par. 0222 the following: “The client-hello message 1001: The client side (e.g. remote TLS client 1010) initiates a TLS handshake by sending the server a client-hello message 1001. This message includes the proposed protocol version, a list of cipher suites supported by the client, and a client random number that will be used in the key generation process.” … teaches in par. 0226 the following: “the client random number (see message 1001), the server random number ……teaches in par. 0226 the following: “the client random number (see message 1001), the server random number (see message 1002), and the pre-master-secret. …teaches in par. 0226 the following: “The client-key-exchange message 1005: The client sends the server this message to begin the process of session key exchange. This message has a pre-master-secret that has been encrypted using the public key of the server. The server public key was sent in the certificate message 1003.” ..teaches in par. 00239 the following: “This public key was sent to the client in the server-hello message 1702”..);
and generating the key agreement data based on the public key included in the ciphertext data (i.e., …teaches in par. 0222 the following: “The client-hello message 1001: The client side (e.g. remote TLS client 1010) initiates a TLS handshake by sending the server a client-hello message 1001. This message includes the proposed protocol version, a list of cipher suites supported by the client, and a client random number that will be used in the key generation process.” …(i.e., …teaches in par. 0047 the following: “Protocol Module 701. This module determines the exact SSL/TLS protocol version being negotiated between the client and the server.” … teaches in par. 0222 the following: “The client-hello message 1001: The client side (e.g. remote TLS client 1010) initiates a TLS handshake by sending the server a client-hello message 1001. This message includes the proposed protocol version, a list of cipher suites supported by the client, and a client random number that will be used in the key generation process.” … teaches in par. 0226 the following: “the client random number (see message 1001), the server random number ……teaches in par. 0226 the following: “the client random number (see message 1001), the server random number (see message 1002), and the pre-master-secret. …teaches in par. 0226 the following: “The client-key-exchange message 1005: The client sends the server this message to begin the process of session key exchange. This message has a pre-master-secret that has been encrypted using the public key of the server. The server public key was sent in the certificate message 1003.” ..teaches in par. 00239 the following: “This public key was sent to the client in the server-hello message 1702”).
As to claims 5 and 16, the system of Ali and Yedidi as applied to claim 1 above teaches a digest verification process, specifically Ali teaches an information verification method according to claim 1, wherein the to-be-verified ciphertext information is generated by the terminal device based on a key ciphertext and a transmission ciphertext (i.e., …teaches in par. 0068 the following: “HMAC for hashed MAC, and MD-5 and SHA-1 for message digest.”),
and the performing the decryption processing comprises: performing decryption processing on the key ciphertext by using a private key corresponding to the public key (i.e., …teaches in par. 0123 the following: “decrypting pre-master secret using the RSA private key.”),
to obtain a random number and a second random number that are used as symmetric keys (i.e. teaches in par. 00222 the following: “and a client random number that will be used in the key generation process.”. …teaches in par. 00223 the following: “a server random number that is used in the key generation process,”);
and performing decryption processing on the transmission ciphertext by using the symmetric keys, to obtain the first information digest (i.e., teaches in par. 0049 the following: “These session keys are then used for the encryption and decryption of application data between the resource-constrained device and the remote server.”. …teaches in par. 0206 the following: “decrypts the incoming application data using the currently established TLS cipher suite and session keys.”).
As to claim 10, Ali teaches an information verification method, performed by a terminal device, the information verification method comprising:
transmitting, to a verification server, a key agreement request upon which key agreement data is obtained at the verification server (i.e., …teaches in par. 0226 the following: “The client-key-exchange message 1005: The client sends the server this message to begin the process of session key exchange.” …teaches in par. 0056 the following: As a result of this handshake, a set of session keys is established, and a secure connection is created with the client.),
the key agreement request including an identifier of a target user (i.e., …teaches in par. 0222 the following: “The client-hello message 1001: The client side (e.g. remote TLS client 1010) initiates a TLS handshake by sending the server a client-hello message 1001. This message includes the proposed protocol version, a list of cipher suites supported by the client, and a client random number that will be used in the key generation process.”),
and the key agreement data comprising a public key (i.e., …teaches in par. 0047 the following: “Protocol Module 701. This module determines the exact SSL/TLS protocol version being negotiated between the client and the server.” … teaches in par. 0222 the following: “The client-hello message 1001: The client side (e.g. remote TLS client 1010) initiates a TLS handshake by sending the server a client-hello message 1001. This message includes the proposed protocol version, a list of cipher suites supported by the client, and a client random number that will be used in the key generation process.” … teaches in par. 0226 the following: “the client random number (see message 1001), the server random number ……teaches in par. 0226 the following: “the client random number (see message 1001), the server random number (see message 1002), and the pre-master-secret. …teaches in par. 0226 the following: “The client-key-exchange message 1005: The client sends the server this message to begin the process of session key exchange. This message has a pre-master-secret that has been encrypted using the public key of the server. The server public key was sent in the certificate message 1003.” ..teaches in par. 00239 the following: “This public key was sent to the client in the server-hello message 1702”..);
receiving the key agreement data from the verification server (i.e., …teaches in par. 0222 the following: “The client-hello message 1001: The client side (e.g. remote TLS client 1010) initiates a TLS handshake by sending the server a client-hello message 1001. This message includes the proposed protocol version, a list of cipher suites supported by the client, and a client random number that will be used in the key generation process.” ……teaches in par. 0226 the following: “the client random number (see message 1001), the server random number (see message 1002), and the pre-master-secret.”);
performing encryption processing on to-be-verified information for a target application by using the public key included in the key agreement data, to obtain to-be-verified ciphertext information, the to-be-verified information comprising user information corresponding to the target user (i.e., …teaches in par. 0047 the following: “This message includes the proposed protocol version, a list of cipher suites supported by the client, and a client random number that will be used in the key generation process.” . …teaches in par. 0193 the following: “The data is encrypted using the agreed upon cipher suite and session keys.”. …teaches in par. 0226 the following: “message has a pre-master-secret that has been encrypted using the public key”. … teaches in par. 0226 the following: “The session keys are generated by using a pseudo random function (PRF) as defined in the TLS 1.0 specification. There are three inputs to this PRF: the client random number (see message 1001), the server random number (see message 1002), and the pre-master-secret.”.);
transmitting, to the verification server, the to-be-verified ciphertext information on which decryption processing is performed to obtain first information digest (i.e., …teaches in par. 0140 the following: “The remote TLS client 1010 sends the client-finish message 1007 to the resource-constrained device. The TSH module 202 on the resource-constrained device receives this message (see FIG. 10). The client-finish message 1007 contains a MAC”),
and the first information digest is matched with second information digest to obtain an information verification result (i.e., …teaches in par. 0140 the following: “The resulting value is then compared with the 12-byte value received in client-finish message 1007.” Teaches in par. 0148 the following: “This hash value is the intermediate digest value, which is used for comparing the corresponding value sent by the remote TLS client 10”.);
and receiving the information verification result from the verification server (i.e., …teaches in par. 0056 the following: As a result of this handshake, a set of session keys is established, and a secure connection is created with the client. …teaches in par. 0230 the following: “sends a corresponding server-finish message to the client.”).
Ali does not expressly teach:
the information verification result indicating a result of logging in to an application server by the terminal device,
without providing the to-be-verified information to the application server,
which is a server of the target application.
In this instance the examiner notes the teachings of prior art reference Yedidi.
With regards to applicant’s claim limitation element of, “the information verification result indicating a result of logging in to an application server by the terminal device”, Yedidi teaches in par. 0058 the following: “login context database 204 (i.e., database 300) can store a database entry (e.g., record) that includes login context data collected for each attempt to log in to a user account managed by content management system 106.”.
With regards to applicant’s claim limitation element of, “without providing the to-be-verified information to the application server”, Yedidi teaches in par. 0051 the following: “When the anonymous proxy metric value (e.g., number of anonymous logins) exceeds a threshold number of anonymous logins,”. Teaches in par. 0059 the following: “content management system 106 can generate a login metric. For example, content management system 106 can generate one or more login metrics based on the login context data stored in login context database 204. The login metrics can include a login frequency metric, an IP addresses metric, a client location metric, a browser types metric, a native clients metric, a login sessions metric, an anonymous proxy metric, a number of devices metric, and/or other login metrics, as described above.”.
With regards to applicant’s claim limitation element of, “which is a server of the target application”, Yedidi teaches in par. 0059 the following: “content management system 106 can generate a login metric. For example, content management system 106 can generate one or more login metrics based on the login context data stored in login context database 204. The login metrics can include a login frequency metric, an IP addresses metric, a client location metric, a browser types metric, a native clients metric, a login sessions metric, an anonymous proxy metric, a number of devices metric, and/or other login metrics, as described above.”.
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the of the claimed invention was made to implement the teachings of Ali with the teachings of Yedidi by having their system comprise an enhanced access login recording process. One would have been motivated to do so to provide a simple and effective means to determine system intrusion, wherein the enhanced access login recording process helps facilitate access security within the network and makes it easier to provide access monitoring.
As to claim 11, the system of Ali and Yedidi as applied to claim 10 above teaches a digest verification process, specifically Ali teaches an information verification method according to claim 10, wherein the performing the encryption processing comprises:
using the first random number and the second random number as symmetric keys used by a symmetric encryption algorithm (i.e., …teaches in par. 0226 the following: “client and the server have all the data they need to generate a set of session keys. The session keys are generated by using a pseudo random function (PRF) as defined in the TLS 1.0 specification. There are three inputs to this PRF: the client random number (see message 1001), the server random number (see message 1002), and the pre-master-secret.”);
performing encryption processing on the symmetric keys by using the public key included in the key agreement data based on an asymmetric encryption algorithm (i.e., …teaches in par. 0068 the following: “RSA for authentication and key exchange, DES and 3-DES for symmetric encryption, HMAC for hashed MAC, and MD-5 and SHA-1 for message digest.” …teaches in par. 0047 the following: “Protocol Module 701. This module determines the exact SSL/TLS protocol version being negotiated between the client and the server.” … teaches in par. 0222 the following: “The client-hello message 1001: The client side (e.g. remote TLS client 1010) initiates a TLS handshake by sending the server a client-hello message 1001. This message includes the proposed protocol version, a list of cipher suites supported by the client, and a client random number that will be used in the key generation process.” … teaches in par. 0226 the following: “the client random number (see message 1001), the server random number ……teaches in par. 0226 the following: “the client random number (see message 1001), the server random number (see message 1002), and the pre-master-secret. …teaches in par. 0226 the following: “The client-key-exchange message 1005: The client sends the server this message to begin the process of session key exchange. This message has a pre-master-secret that has been encrypted using the public key of the server. The server public key was sent in the certificate message 1003.” ..teaches in par. 00239 the following: “This public key was sent to the client in the server-hello message 1702”..),
to obtain key ciphertexts of the symmetric keys (i.e. ,…teaches in par. 0228 the following: “This message is encrypted using the cryptographic algorithm and keys selected during the TLS handshake”);
performing digest calculation on the to-be-verified information for the target application based on a hash function encryption algorithm (i.e., …teaches in par. 0068 the following: “RSA for authentication and key exchange, DES and 3-DES for symmetric encryption, HMAC for hashed MAC, and MD-5 and SHA-1 for message digest.”), to obtain the first information digest (i.e, …teaches in par. 00228 the following: “message body consists of a digest”);
performing encryption processing on the symmetric keys and the first information digest based on the symmetric encryption algorithm (i.e., …teaches in par. 0230 the following: “message is encrypted using the selected cipher suite, and session keys”),
to obtain a transmission ciphertext (i.e., …teaches in par. 0230 the following: “message is encrypted using the selected cipher suite, and session keys”);
and generating the to-be-verified ciphertext information based on the key ciphertexts and the transmission ciphertext (i.e., …teaches in par. 0230 the following: “message is encrypted using the selected cipher suite, and session keys”).
As to claim 13, the system of Ali and Yedidi as applied to claim 12 above teaches a digest verification process, specifically Ali teaches an information verification apparatus according to claim 12, wherein the obtaining the key agreement data comprises:
transmitting sub-code configured to cause the at least one processor to transmit a ciphertext generation request to an encryptor(i.e. …teaches in par.0068 the following: “’ Crypto Module 206 supports various cryptographic algorithms that are used in the implementation of SSL/TLS protocols. Examples of these algorithms are: RSA for authentication and key exchange, DES and 3-DES for symmetric encryption, HMAC for hashed MAC, and MD-5 and SHA-1 for message digest.”);
receiving sub-code configured to cause the at least one processor to receive, from the encryptor, ciphertext data generated based on the ciphertext generation request (i.e., …teaches in par. 0151 the following: “The resulting record (i.e. concatenation of the data segment and its MAC) is encrypted using the session keys and algorithms established during the TLS handshake”),
the ciphertext data comprising the public key and a first random number (i.e., …teaches in par. 0222 the following: “The client-hello message 1001: The client side (e.g. remote TLS client 1010) initiates a TLS handshake by sending the server a client-hello message 1001. This message includes the proposed protocol version, a list of cipher suites supported by the client, and a client random number that will be used in the key generation process.” …teaches in par. 0047 the following: “Protocol Module 701. This module determines the exact SSL/TLS protocol version being negotiated between the client and the server.” … teaches in par. 0222 the following: “The client-hello message 1001: The client side (e.g. remote TLS client 1010) initiates a TLS handshake by sending the server a client-hello message 1001. This message includes the proposed protocol version, a list of cipher suites supported by the client, and a client random number that will be used in the key generation process.” … teaches in par. 0226 the following: “the client random number (see message 1001), the server random number ……teaches in par. 0226 the following: “the client random number (see message 1001), the server random number (see message 1002), and the pre-master-secret. …teaches in par. 0226 the following: “The client-key-exchange message 1005: The client sends the server this message to begin the process of session key exchange. This message has a pre-master-secret that has been encrypted using the public key of the server. The server public key was sent in the certificate message 1003.” ..teaches in par. 00239 the following: “This public key was sent to the client in the server-hello message 1702”);
generating sub-code configured to cause the at least one processor to generate the key agreement data based on the public key and the first random number included in the ciphertext data. (i.e., …teaches in par. 0222 the following: “The client-hello message 1001: The client side (e.g. remote TLS client 1010) initiates a TLS handshake by sending the server a client-hello message 1001. This message includes the proposed protocol version, a list of cipher suites supported by the client, and a client random number that will be used in the key generation process.” …teaches in par. 0047 the following: “Protocol Module 701. This module determines the exact SSL/TLS protocol version being negotiated between the client and the server.” … teaches in par. 0222 the following: “The client-hello message 1001: The client side (e.g. remote TLS client 1010) initiates a TLS handshake by sending the server a client-hello message 1001. This message includes the proposed protocol version, a list of cipher suites supported by the client, and a client random number that will be used in the key generation process.” … teaches in par. 0226 the following: “the client random number (see message 1001), the server random number ……teaches in par. 0226 the following: “the client random number (see message 1001), the server random number (see message 1002), and the pre-master-secret. …teaches in par. 0226 the following: “The client-key-exchange message 1005: The client sends the server this message to begin the process of session key exchange. This message has a pre-master-secret that has been encrypted using the public key of the server. The server public key was sent in the certificate message 1003.” ..teaches in par. 00239 the following: “This public key was sent to the client in the server-hello message 1702”).
As to claim 17, the system of Ali and Yedidi as applied to claim 1 above teaches a digest verification process, specifically Ali teaches a server, comprising:
a memory, a processor, and a bus system, the memory being configured to store a program (i.e., …figure 19 teaches a memory, processor and bus connection),
the processor being configured to execute the program in the memory to perform the method according to claim 1 (i.e., …figure 19 teaches a memory, processor and bus connection);
and the bus system being configured to connect the memory and the processor (i.e., …figure 19 teaches a memory, processor and bus connection).
As to claim 18, the system of Ali and Yedidi as applied to claim 10 above teaches a digest verification process, specifically Ali teaches a terminal device, comprising: a memory, a processor, and a bus system, the memory being configured to store a program (i.e., …figure 19 teaches a memory, processor and bus connection), the processor being configured to execute the program in the memory to perform the method according to claim 10 (i.e., …figure 19 teaches a memory, processor and bus connection); and the bus system being configured to connect the memory and the processor (i.e., …figure 19 teaches a memory, processor and bus connection).
As to claim 19, the system of Ali and Yedidi as applied to claim 1 above teaches a digest verification process, specifically Ali teaches a non-transitory computer-readable storage medium (i.e., …teaches in par. 0214 the following: “instructions in the various software modules stored in the ROM”), comprising instructions, the instructions, when run on a computer, causing the computer to perform the method according to claim 1 (i.e., …teaches in par. 0214 the following: “instructions in the various software modules stored in the ROM”).
As to claim 20, the system of Ali and Yedidi as applied to claim 10 above teaches a digest verification process, specifically Ali teaches a non-transitory computer-readable storage medium (i.e., …teaches in par. 0214 the following: “instructions in the various software modules stored in the ROM”), comprising instructions, the instructions, when run on a computer, causing the computer to perform the method according to claim 10 (i.e., …teaches in par. 0214 the following: “instructions in the various software modules stored in the ROM”).
Allowable Subject Matter
Claim 3 is 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.
The following is an examiner’s statement of reasons for allowance: “wherein the ciphertext data further comprises a public key index value, the public key index value uniquely corresponding to the public key;
the generating the key agreement data comprises: generating a session identifier based on the identifier of the target user included in the key agreement request;
and generating the key agreement data based on the session identifier and the public key the verification method further comprising:
establishing a mapping relationship between the session identifier, the public key, and the public key index value; and wherein the performing the decryption processing comprises:
performing, based on the mapping relationship and the session identifier, the decryption processing on the to-be-verified ciphertext information, to obtain the first information digest.”.
Dependent claim 4 is allowable based on its dependency on dependent claim 3.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Claim 6 is 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.
The following is an examiner’s statement of reasons for allowance: “prior to the matching the first information digest with the second information digest:
obtaining a key index value and to-be-matched ciphertext information from a database; transmitting the key index value and the to-be-matched ciphertext information to an encryptor;
and invoking the encryptor to perform decryption processing on the to-be-matched ciphertext information, to obtain the second information digest, the second information digest being obtained by the encryptor by performing decryption processing on the to-be-matched ciphertext information by using an information encryption key,
the information encryption key being determined based on the key index value”.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Claim 7 is 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.
The following is an examiner’s statement of reasons for allowance: “after the matching the first information digest with the second information digest:
generating a token based on the information verification result indicating that verification succeeds, a preset usage cycle being set for the token;
transmitting the token to the terminal device;
obtaining, based on an application login request from the terminal device being received, a usage time of the token in response to the application login request, the application login request including the token;
and transmitting an application login success message to the terminal device based on the usage time of the token being within the preset usage cycle”.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Claim 8 is 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.
The following is an examiner’s statement of reasons for allowance: “receiving an authentication request from the application server,
the authentication request including an application key index and an application key;
performing verification processing on the application key index and the application key in response to the authentication request, to obtain a verification result;
and performing, based on the verification result being successful, the obtaining the key agreement data in response to the key agreement request”.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Claim 9 is 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.
The following is an examiner’s statement of reasons for allowance: “receiving an authentication request from the application server, the authentication request including an application key index, a timestamp, a signature random number, and first signature information, the first signature information being obtained by signing a first application key, the timestamp, and the signature random number based on a hash function encryption algorithm;
obtaining a second application key in response to the authentication request and based on the application key index;
signing the second application key, the timestamp, and the signature random number based on the hash function encryption algorithm, to obtain second signature information;
and performing, based on the first signature information and the second signature information being successfully matched, the obtaining the key agreement data in response to the key agreement request”.
Claim 14 is 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.
The following is an examiner’s statement of reasons for allowance: “wherein the ciphertext data further comprises a public key index value, the public key index value uniquely corresponding to the public key;
the generating sub-code is configured to cause the at least one processor to generate a session identifier based on the identifier of the target user included in the key agreement request;
and generate the key agreement data based on the session identifier, the public key, and the first random number;
wherein the program code further comprises: establishing code configured to cause the at least one processor to establish a mapping relationship between the session identifier, the public key, the first random number, and the public key index value,
and wherein the decryption code is configured to cause the at least one processor to perform, based on the mapping relationship and the session identifier, the decryption processing on the to-be-verified ciphertext information, to obtain the first information digest”.
Dependent claim 15 is allowable based on its dependency on dependent claim 14.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRYAN F WRIGHT whose telephone number is (571)270-3826.
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, Eleni Shiferaw can be reached on (571)272-3867. 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.
/BRYAN F WRIGHT/Examiner, Art Unit 2497
Prosecution Insights