DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
The amendment filed 6/23/2026 has been entered. Claims 1, 7-8, 14-15, 20 are currently amended. Claims 2-4, 9-11, 16-17 are cancelled. Claims 21-22 are originally cancelled claims. Claims 1, 5-8, 12-15, 18-20 are pending in the application.
Response to Amendment
The rejection to claims 7, 14, 20 under 35 USC 112(b) has been withdrawn in light of applicant’s amendment to the claims.
Response to Arguments
Applicant’s arguments, see pages 7-10 of the Remarks filed 6/23/2026 with respect to claims rejected under 35 USC 103 over prior arts of record has been fully considered and asserted not persuasive.
Examiner acknowledges that applicant amended independent claims 1, 8, 15 respectively by specifying underlined reciting “a value of the certificate compression function field indicates whether the client supports a certificate compression function”, and “wherein the compressed serving end certificate is generated by the serving end by performing compression processing based on a preset compression algorithm, and wherein the serving end sends the compressed serving end certificate without including any algorithm confirmation field in the serving end certificate message or any other message sent to the client to indicate which compression algorithm was used”. Applicant argued the prior arts of records, in particular, Ghedini fails to teach the amended limitations, see pages 8-9 of the Remarks.
Examiner acknowledges applicant’s perspective however respectively disagrees.
First, Ghedini teaches a value of the certificate compression function field indicates whether the client supports a certificate compression function. For instance, Ghedini states “If the peer has indicated that it supports compression, server and client may compress their corresponding Certificate messages (Section 4. Compressed Certificate Message). It is understandable from Ghedini that the server or client may compress corresponding certificate message based on whether (binary indication) the peer (client or server) indicates it supports the compression. Examiner also notices that the claimed invention includes a value of the certificate compression function field that is used to indicate a compression algorithm supported by the client, and a value of the certificate compression function field that can be used to indicate whether the client supports the certificate compression function, see applicant’s Specification para. [0029-0030]. Ghedini teaches both values.
Second, regarding preset compression algorithm, applicant argued, “the claim expressly requires that the serving end sends the compressed serving end certificate without including any algorithm confirmation field in the serving end certificate message or any other message sent to the client to indicate which compression algorithm was used”. See page 8-9 of the Remarks. Applicant is directed to claim rejection under 35 USC 112(a). The amended claim does not specify how the preset compression algorithm was preset or agreed upon between serving end and client, instead recites negative limitation of “without including any algorithm confirmation field in the serving end certificate message or any other message sent to the client to indicate which compression algorithm was used”. One ordinary skilled in the art will wonder how the client is able to know the preset compression algorithm and decompress the compressed serving end certificate.
For the above reason, the claim rejections under 35 USC 103 of independent claims 1, 8, 15 is maintained.
Applicant’s further argument on dependent claims, see pages 9-10, is not persuasive for the same reason set forth above.
Applicant is encouraged to further include innovative features into the independent claims to advance the case.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 5-8, 12-15, 18-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 1, similarly claim 8, 15, recites “wherein the compressed serving end certificate is generated by the serving end by performing compression processing based on a preset compression algorithm, and wherein the serving end sends the compressed serving end certificate without including any algorithm confirmation field in the serving end certificate message or any other message sent to the client to indicate which compression algorithm was used”.
First, upon review of applicant’s Specification, the examiner is not able to find written description that support the underlined above. Para. [0036] of the Specification only states “If the client supports the certificate compression function, the serving end can compress the serving end certificate based on the preset compression algorithm without a need to negotiate with the client, to generate the compressed serving end certificate”, instead of without including any algorithm confirmation field in the serving end certificate message or any other message sent to the client to indicate which compression algorithm was used. Applicant’s argument further stated, “By contrast, the present claim explicitly excludes such a field-the serving end sends the compressed certificate without any algorithm confirmation field. This is a direct structural difference between the claimed method and the method taught by Ghedini”. However, examiner is not able to find written description that supports applicant’s argument above.
Second, the claim recites “preset compression algorithm” that the serving end used to compress the serving end certificate, and the client used to decompress the compressed serving end certificate. It is not clear how the client is able to know to use the preset compression algorithm, i.e., the preset compression algorithm should be known/available to the client. Applicant is requested to response with evidence that shows a written description that supports the amended limitations above.
Claims 5-7, 12-14, 18-20 depend on claims 1, 8, 15 respectively, therefore are rejected for the same reason set forth above.
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-15 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 lines 4-5 recites “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”. There is insufficient antecedent basis for these limitations underlined above in the claim.
Similarly, claim 14 lines 4-6.
Claim 15 line 14 recites “the preset compression”. There is insufficient antecedent basis for these limitations underlined above in the claim.
Examiner Notes
Examiner cites particular paragraphs, columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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, 5-8 , 12-15, 18-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 a value of the certificate compression function field indicates whether 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, wherein the compressed serving end certificate is generated by the serving end by performing compression processing based on a preset compression algorithm, and wherein the serving end sends the compressed serving end certificate without including any algorithm confirmation field in the serving end certificate message or any other message sent to the client to indicate which compression algorithm was used; 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 based on the preset compression algorithm], (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 a value of the certificate compression function field indicates whether 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. And Section 4. Compressed Certificate Message: If the peer has indicated that it supports compression, server and client MAY compress their corresponding Certificate messages),
wherein the serving end certificate message comprises a compressed serving end certificate, wherein the compressed serving end certificate is generated by the serving end by performing compression processing based on a preset compression algorithm, and wherein the serving end sends the compressed serving end certificate without including any algorithm confirmation field in the serving end certificate message or any other message sent to the client to indicate which compression algorithm was used (Section 7.3. Compressed Algorithms lists compression algorithms that can be interpretated as preset compression algorithm);
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 based on the preset compression algorithm (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 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 compressed 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 compressed 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:
Truskovsky et al (US20120124375A1) discloses system and method for verifying server certificates.
Sharifi Mehr (US9888037B1) discloses methods that client and a server negotiate a cipher suite as part of establishing a TLS connection.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights