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 .
This is a non-final office action in response to applicant’s preliminary amendment filed on 11/26/2024.
Claims 6, 13, 19 are amended claims. Claims 21-22 are cancelled. Claims 1-20 are pending and being considered.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. CN202210602389.1, filed on 5/30/2022. The instant application is a 371 of PCT/CN2023/094756 filed on 5/17/2023.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/26/2024, 7/24/2025, has been considered. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, initialed and dated copy of Applicant’s IDS forms 1449 filed as stated above is/are attached to the instant Office Action.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 7, 14, 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 7 line 1 recites “the client certificate”. There is insufficient antecedent basis for this limitation in the claim. Applicant is suggested to recite “the compressed client certificate”.
Similarly, for claims 14, 20.
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, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Trere et al (US20210184869A1, hereinafter, “Trere”), in view of Ghedini et al ("RFC 8879 - TLS Certificate Compression", 1 December 2020 (2020-12-01)-IDS, hereinafter, “Ghedini”).
Regarding claim 1, Trere teaches:
An identity verification method in a handshake process for a TLCP protocol (Trere, discloses method of mutual authentication handshake for systems with low-throughput communication links with TLS protocol (i.e., TLCP protocol in global industry standard for encryption). Examiner further notes, TLCP and TLS are understood as being both security protocols, TLS is the global industry standard, while TLCP is a specific Chinese national standard. Therefore, TLS is equivalent to TLCP), comprising:
sending, by a client, a client hello message to a serving end (Fig. 1 shows Handshake messaging phase where First Party 102 being client and Second Party 104 being serving end, as further shown in Fig. 7. And Fig. 1 at 106 shows Exchange identity information which includes digital certificates for sharing information about the party, see [0037]), [wherein the client hello message comprises a certificate compression function field, and the certificate compression function field indicates that the client supports a certificate compression function];
sending, by the serving end, a serving end certificate message to the client when the serving end receives the client hello message (Fig. 1 and Fig. 7 in mutual authentication, and [0036] In operation 106, first party 102 and second party 104 exchange respective identity information by performing first messaging of handshake messaging phase 118. First messaging may include each of the first party 102 and second party 104 sending a message (a first and second message, respectively) with its respective identify information (which may include an optional cryptographic nonce), which message is received by the other party. And [0037] Identity information may include, or be in the form of, one or more digital certificates for sharing information about the party), [wherein the serving end certificate message comprises a compressed serving end certificate; and in response to the serving end certificate message, decompressing, by the client, the compressed serving end certificate comprised in the serving end certificate message], (See Ghedini below for teachings of limitations in brackets above)
while Trere teaches the mutual authentication for identity verification in handshake by exchanging messages including certificate between client and server with TLS protocol, but does not specifically teach the following limitations, in the same field of endeavor Ghedini teaches:
wherein the client hello message comprises a certificate compression function field, and the certificate compression function field indicates that the client supports a certificate compression function (Ghedini, discloses TLS certificate compression in TLS handshakes, [Abstract] “… describes how certificate chains can be compressed to reduce the amount of data transmitted”. And Section 3. Negotiating Certificate Compression: This document defines a new extension type (compress_certificate(27)), which can be used to signal the supported compression formats for the Certificate message to the peer. Whenever it is sent by the client as a ClientHello message extension (i.e., certificate compression function field)…, it indicates support for compressed server certificates. Whenever it is sent by the server as a CertificateRequest extension …, it indicates support for compressed client certificates. By sending a compress…certificate extension, the sender indicates to the peer the certificate-compression algorithms it is willing to use for decompression),
wherein the serving end certificate message comprises a compressed serving end certificate (Section 4. Compressed Certificate Message: If the peer has indicated that it supports compression, server and client MAY compress their corresponding Certificate messages… and send them in the form of the CompressedCertificate message);
and in response to the serving end certificate message, decompressing, by the client, the compressed serving end certificate comprised in the serving end certificate message (Section 4. Compressed Certificate Message: uncompressed length: The presence of this field allows the receiver to preallocate the buffer for the uncompressed Certificate message and enforce limits on the message size before performing decompression),
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have employed the teachings of Ghedini in the TLS handshake for mutual authentication of Trere by compression of peer certificate in handshake. This would have been obvious because the person having ordinary skill in the art would have been motivated to reduce the amount of data and avoid some round trips (Ghedini, [Abstract]).
The combination of Trere and Ghedini further teaches: and performing identity verification on the serving end based on an obtained decompressed serving end certificate (Trere discloses mutual authentication between client and server (i.e., identity verification), and Ghedini discloses certificate compression and decompression for TLS handshake).
Regarding claim 8, claim 8 is a method claim that encompasses limitations that are similar to those limitations of the method claim 1, except claim 8 is recited as applied to a client. The teachings of Trere and Ghedini in claim 1 applied to both client and server. Therefore, claim 8 is rejected with the same rational and motivation as applied above to claim 1.
Regarding claim 15, claim 15 is a method claim that encompasses limitations that are similar to those limitations of the method claim 1, except claim 15 is recited as applied to a serving end. The teachings of Trere and Ghedini in claim 1 applied to both client and server (i.e., serving end). Therefore, claim 15 is rejected with the same rational and motivation as applied above to claim 1.
Regarding claim 2, similarly claim 9, claim 16, Trere-Ghedini combination teaches the method according to claim 1, the method according to claim 8, the method according to claim 15,
Ghedini further teaches: wherein a value of the certificate compression function field is used to indicate a compression algorithm supported by the client, and the method further comprises: selecting, by the serving end from the compression algorithm supported by the client, a target compression algorithm supported by the serving end, to generate the compressed serving end certificate; and sending, by the serving end, a serving end hello message to the client in response to the client hello message, wherein the serving end hello message comprises a certificate compression function confirmation field, and a value of the certificate compression function confirmation field corresponds to the target compression algorithm, wherein the decompressed serving end certificate is obtained by the client by performing decompression processing based on the target compression algorithm (Section 3. Negotiating Certificate Compression: Whenever it is sent by the client as a ClientHello message extension (i.e., certificate compression function field)…, it indicates support for compressed server certificates. And Section 7.3 defines Compression Algorithms and Algorithm Number (i.e., value of the certificate compression function field). It is understandable Ghedini’s teachings of claim 1 further teaches the rest of limitations in claim 2 in regard to compression algorithms, thereafter decompression algorithms). Same motivation as presented in claim 1, 8, 15 would apply.
Regarding claim 3, similarly claim 10, Trere-Ghedini combination teaches the method according to claim 2, the method according to claim 9,
Ghedini further teaches: wherein the method further comprises: parsing, by the client, the certificate compression function confirmation field in the received serving end hello message, and sending an alarm message to the serving end when the value of the certificate compression function confirmation field indicates that the target compression algorithm does not belong to the compression algorithm supported by the client or a quantity of target compression algorithms is greater than 1 (Section 4. Compressed Certificate Message: If the specified compression algorithm is zL1b, then the Certificate message MUST be compressed with the ZLIB compression algorithm… If the received CompressedCertificate message cannot be decompressed, the connection MUST be terminated with the "bad certificate" alert). Same motivation as presented in claim 1, 8 would apply.
Regarding claim 4, similarly claim 11, claim 17, Trere-Ghedini combination teaches the method according to claim 1, the method according to claim 8, the method according to claim 15,
Ghedini further teaches: wherein a value of the certificate compression function field is used to indicate whether the client supports the certificate compression function, the compressed serving end certificate is generated by the serving end by performing compression processing based on a preset compression algorithm, and the decompressed serving end certificate is obtained by the client by performing decompression processing based on the preset compression algorithm (Section 3. Negotiating Certificate Compression: Whenever it is sent by the client as a ClientHello message extension (i.e., certificate compression function field)…, it indicates support for compressed server certificates. And Section 7.3 defines Compression Algorithms and Algorithm Number (i.e., value of the certificate compression function field). Same motivation as presented in claim 1, 8, 15 would apply.
Regarding claim 5, similarly claim 12, claim 18, Trere-Ghedini combination teaches the method according to claim 1, the method according to claim 8, the method according to claim 15,
Ghedini further teaches: further comprising: when the serving end or the client does not support the certificate compression function, sending, by the serving end to the client, a serving end certificate message that carries an uncompressed serving end certificate (Section 4. Compressed Certificate Message: compressed_certificate_message: The result of applying the indicated compression algorithm to the encoded Certificate message that would have been sent if certificate compression was not in use). Same motivation as presented in claim 1, 8, 15 would apply.
Regarding claim 6, similarly claim 13, claim 19, Trere-Ghedini combination teaches the method according to claim 1, the method according to claim 8, the method according to claim 15,
The combination of Trere and Ghedini further teaches: further comprising: sending, by the serving end, a certificate request message to the client; when the client receives the certificate request message, sending, by the client, a client certificate message to the serving end, wherein the client certificate message comprises a compressed client certificate, and sending, by the client, a certificate verification message to the serving end, wherein the certificate verification message comprises a client signature; and in response to the client certificate message, decompressing, by the serving end, the compressed client certificate comprised in the client certificate message, and performing identity verification on the client based on an obtained decompressed client certificate and the client signature comprised in the received certificate verification message (Trere teaches mutual authentication handshake, that applies to client and server, therefore the teachings of Trere and Ghedini in claim 1 for authenticating the server also apply to authenticating the client by exchanging identity information between the client and the server. And [0043] each party verifies the other party's identity using the exchanged identity information, as a non-limiting example, using an ECDSA verification process. In a case of a device certificate and signer certificate arranged in a certificate chain, for each party, verification in operations 108 and 110 may include verifying a signer's signature applied to the signed device certificate portion using ECDSA verification and a signer's public key included with a signer's public key certificate signed by a certificate authority. And Ghedini’s Section 3 also teaches the mutual aspect in handshake, “Whenever it is sent by the client as a ClientHello message extension (i.e., certificate compression function field)…, it indicates support for compressed server certificates. Whenever it is sent by the server as a CertificateRequest extension …, it indicates support for compressed client certificates”). Same motivation as presented in claim 1, 8, 15 would apply.
Regarding claim 7, similarly claim 14, claim 20, Trere-Ghedini combination teaches the method according to claim 6, the method according to claim 13, the method according to claim 19,
Ghedini further teaches: wherein the client certificate is obtained by the client by performing compression processing based on the preset compression algorithm; or when the client determines the corresponding target compression algorithm based on the value of the certificate compression function confirmation field in the serving end hello message, the client certificate is obtained by the client by performing compression processing based on the target compression algorithm (Section 3. Negotiating Certificate Compression: Whenever it is sent by the client as a ClientHello message extension (i.e., certificate compression function field)…, it indicates support for compressed server certificates. And Section 7.3 defines Compression Algorithms and Algorithm Number (i.e., value of the certificate compression function field). Same motivation as presented in claim 1, 8, 15 would apply.
Citation of References
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The following references are cited but not been replied upon for this office action:
Campagna et al (US20180343127A1) discloses system and method of first entity and a second entity establishing a protected authenticated communication channel using an implicit certificate.
Huang et al (CN111629002A) discloses method for security upgrading for vehicle ECU for performing authentication through different certificates.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL M LEE whose telephone number is (571)272-1975.
The examiner can normally be reached on M-F: 8:30AM - 5:30PM.
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, Shewaye Gelagay can be reached on (571) 272-4219. 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.
/MICHAEL M LEE/Primary Examiner, Art Unit 2436