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 action is in response to the communication filed on April 20, 2026 in response to the Non-Final Office Action.
Remarks
Pending claims for reconsideration are claims 1-16. Applicant has
Amended claims 1, 5, and 9.
Response to Arguments
Applicant’s arguments filed on April 20, 2026 with respect to amended claims have been considered but they are deemed moot in view of the new grounds of rejection (see 103 rejection below).
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 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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- 16 are rejected under 35 U.S.C. 103 as being unpatentable over de Andrada et al. (U.S. Patent Publication No.: US 9,692,603 B2 / or “de Andrada” hereinafter) in view of Dutta et al. (U.S. Patent Application Publication No.: US 2024/0333470 A1 / or “Kumar” hereinafter).
Regarding claim 1, de Andrada discloses “A certificate requesting method executed by a mobile device, the mobile device comprising a built-in security chip and an external security chip, and the certificate requesting method comprising” (Fig. 1: Mobile Device 105 i.e., a “mobile device” with a Key Store 150 i.e. , a “built-in security chip”; and Fig. 3: Mobile Device with a Smart Card 205 i.e., an “external security chip”):
“generating a pair of a built-in public key and a built-in private key in the built-in security chip, [wherein the built-in private key cannot be exported from the built-in security chip]” (Fig. 1A: Public/Private Key Pair; and Col 2: lines 24-36, the key pair is generated by the Mobile Device 105 and Fig. 5A: Step 500);
“generating a certificate signing request according to the built-in private key, wherein the certificate signing request includes subscriber identity identification information and the built-in public key” (Fig. 5A: Step 505, Mobile device generates certificate signing request (CSR) including the public key and a Mobile Directory Number (MDN) i.e., “subscriber identity identification information” where the request is signed with the private key; and Col 3:46-49; and Col 6: lines 57-64);
“sending the certificate signing request to a certificate authority server to receive a confirmation code sent by the certificate authority server” (Fig. 5A: Step 510, the Mobile Device sends signed CSR to a certificate authority; and Fig. 5: Step 515, the Server 104 send an authentication and key agreement (AKA) challenge i.e., a “confirmation code”; and Col 7: lines 1-21);
“signing the confirmation code with an external private key that is contained in the external security chip, [wherein the external private key cannot be exported from the external security chip], and then sending the confirmation code to the certificate authority server” (Fig. 5A: Step 525, the Smart Card 205 i.e., the “external security chip” calculates AKA response with a private key; and Col 7: lines 21-25; Note: AKA protocol involve use of a shared secret session key for data communication/authentication);
“and downloading a public key certificate from the certificate authority server, wherein the public key certificate includes the subscriber identity identification information and the built-in public key” (Fig. 5B: Step 540, the mobile device receives certificate authority signed digital certificate; and Col 7: lines 45-64, the certificate includes the public key and name or identity to whom the certificate was issued among other things).
But de Andrada to specially disclose a secure module having a public/private key pair used in authentication of confirmation code/certificate signing request.
However, Dutta discloses a secure module having a public/private key pair used in authentication of confirmation code/certificate signing request (see, Dutta, Fig. 5 and Para 0144: a secure element with asymmetric cryptographic operation ability and sings the certificate signing request using the private of the secure element; and Para 0101-0109).
It would have been obvious to an ordinary person skilled in the art before the effective filing date of the claimed invention to employ the teachings of a secure module having a public/private key pair used in authentication of confirmation code/certificate signing request of Dutta to the Biometric PKI Authentication of de Andrada to create a system where the secure element help authenticate a user by signing certificate request and the ordinary person skilled in the art would have been motivated to combine to authenticated communication (Dutta, Para 0101-0109).
Regarding claim 2, in view of claim 1, de Andrada discloses “wherein the external security chip includes a public key infrastructure module and a wireless communications module, and the signing and sending of the confirmation code comprise: enabling the public key infrastructure module to sign the confirmation code with the external private key; and enabling the wireless communications module to send the confirmation code to the certificate authority server” (Fig. 5A: Step 525, the Smart Card 205 i.e., the “external security chip” calculates AKA response with a private key; and Col 7: lines 21-25; Note: AKA protocol involve use of a shared secret session key for data communication/authentication).
Regarding claim 3, in view of claim 1, de Andrada discloses in view of Dutta disclose “wherein the external security chip includes a public key infrastructure module, the external security chip supports a wireless communications protocol or is disposed in a carrier supporting the wireless communications protocol, and the signing of the confirmation code comprises: sending an instruction via the wireless communications protocol, so that the public key infrastructure module uses the external private key to sign the confirmation code” (Dutta, Fig. 5 and Para 0144: a secure element with asymmetric cryptographic operation ability and sings the certificate signing request using the private of the secure element; and Para 0101-0109).
Regarding claim 4, in view of claim 1, de Andrada discloses “further comprising: storing the public key certificate in a password-protected area of an operating system of the mobile device” (Fig. 1: Mobile Device 105 i.e., a “mobile device” with a Key Store 150 i.e. , a “built-in security chip” stored the public key certificate).
Regarding claim 5, de Andrada discloses “A certificate issuing method executed by a certificate authority server, and the certificate issuing method comprising” (Fig. 1B: Certificate Authority (CA) 175):
“receiving a certificate signing request sent by a mobile device, wherein the certificate signing request includes subscriber identity identification information and a built-in public key in a built-in security chip of the mobile device” (Fig. 5A: Step 505, Mobile device generates certificate signing request (CSR) including the public key and a Mobile Directory Number (MDN) i.e., “subscriber identity identification information” where the request is signed with the private key; and Col 3:46-49; and Col 6: lines 57-64);
“generating a confirmation code according to the certificate signing request to send the confirmation code to the mobile device” (Fig. 5A: Step 510, the Mobile Device sends signed CSR to a certificate authority; and Fig. 5: Step 515, the Server 104 send an authentication and key agreement (AKA) challenge i.e., a “confirmation code”; and Col 7: lines 1-21);
“and receiving the confirmation code signed by an external private key that is contained in an external security chip of the mobile device, [wherein the external private key cannot be exported from the external security chip[” (Fig. 5A: Step 525, the Smart Card 205 i.e., the “external security chip” calculates AKA response with a private key; and Col 7: lines 21-25; Note: AKA protocol involve use of a shared secret session key for data communication/authentication),
“and then using an [external public key] corresponding to the external private key to verify the confirmation code, wherein a public key certificate is issued when the verification of the confirmation code is successful” (Col 7: lines 48-54, the certificate authority validates the AKA response received from the mobile device),
“and then the public key certificate is sent to the mobile device, and wherein the public key certificate includes the subscriber identity identification information and the built-in public key” (Fig. 5B: Step 540, the mobile device receives certificate authority signed digital certificate; and Col 7: lines 45-64, the certificate includes the public key and name or identity to whom the certificate was issued among other things).
But de Andrada to specially disclose a secure module having a public/private key pair used in authentication of confirmation code/certificate signing request.
However, Dutta discloses a secure module having a public/private key pair used in authentication of confirmation code/certificate signing request (see, Dutta, Fig. 5 and Para 0144: a secure element with asymmetric cryptographic operation ability and sings the certificate signing request using the private of the secure element; and Para 0101-0109).
It would have been obvious to an ordinary person skilled in the art before the effective filing date of the claimed invention to employ the teachings of a secure module having a public/private key pair used in authentication of confirmation code/certificate signing request of Dutta to the Biometric PKI Authentication of de Andrada to create a system where the secure element help authenticate a user by signing certificate request and the ordinary person skilled in the art would have been motivated to combine to authenticated communication (Dutta, Para 0101-0109).
Regarding claim 6, in view of claim 5, de Andrada discloses “wherein the confirmation code is generated according to the certificate signing request and a random number” (Fig. 5A: Step 505, Mobile device generates certificate signing request (CSR) including the public key and a Mobile Directory Number (MDN) i.e., “subscriber identity identification information” where the request is signed with the private key; and Col 3:46-49; and Col 6: lines 57-64).
Regarding claim 7, in view of claim 5, de Andrada in view of Dutta disclose “wherein the verification of the confirmation code comprises: obtaining the external public key corresponding to the external private key from a plurality of public keys of a plurality of subscribers according to the subscriber identity identification information to verify the confirmation code” (Dutta, Fig. 5 and Para 0144: a secure element with asymmetric cryptographic operation ability and sings the certificate signing request using the private of the secure element; and Para 0101-0109).
Regarding claim 8, in view of claim 5, de Andrada discloses “further comprising: not issuing and not sending the public key certificate if the verification of the confirmation code fails” (Col 7: lines 48-57, certificate is only issued when AKA response is validated).
Regarding claim 9, de Andrada discloses “A certificate system comprising a mobile device and a certificate authority server that are communicatively connected to each other, wherein the mobile device includes a built-in security chip and an external security chip to perform” (Fig. 1: Mobile Device 105 i.e., a “mobile device” with a Key Store 150 i.e. , a “built-in security chip”; and Fig. 3: Mobile Device with a Smart Card 205 i.e., an “external security chip”):
“generating a pair of a built-in public key and a built-in private key in the built-in security chip, wherein the built-in private key cannot be exported from the built-in security chip” (Fig. 1A: Public/Private Key Pair; and Col 2: lines 24-36, the key pair is generated by the Mobile Device 105 and Fig. 5A: Step 500);
“generating a certificate signing request according to the built-in private key, wherein the certificate signing request includes subscriber identity identification information and the built-in public key” (Fig. 5A: Step 505, Mobile device generates certificate signing request (CSR) including the public key and a Mobile Directory Number (MDN) i.e., “subscriber identity identification information” where the request is signed with the private key; and Col 3:46-49; and Col 6: lines 57-64);
“sending the certificate signing request to the certificate authority server to receive a confirmation code sent by the certificate authority server” (Fig. 5A: Step 510, the Mobile Device sends signed CSR to a certificate authority; and Fig. 5: Step 515, the Server 104 send an authentication and key agreement (AKA) challenge i.e., a “confirmation code”; and Col 7: lines 1-21);
“signing the confirmation code with an external private key in the that is contained in the external security chip, wherein the external private key cannot be exported from the external security chip” ((Fig. 5A: Step 525, the Smart Card 205 i.e., the “external security chip” calculates AKA response with a private key; and Col 7: lines 21-25; Note: AKA protocol involve use of a shared secret session key for data communication/authentication);
“and downloading a public key certificate from the certificate authority server, wherein the public key certificate includes the subscriber identity identification information and the built-in public key” (Fig. 5B: Step 540, the mobile device receives certificate authority signed digital certificate; and Col 7: lines 45-64, the certificate includes the public key and name or identity to whom the certificate was issued among other things).
“and the certificate authority server executes: receiving the certificate signing request sent by the mobile device” (Fig. 5A: Step 510, the Mobile Device sends signed CSR to a certificate authority;);
“generating the confirmation code according to the certificate signing request, so as to send the confirmation code to the mobile device” ( Fig. 5: Step 515, the Server 104 send an authentication and key agreement (AKA) challenge i.e., a “confirmation code”; and Col 7: lines 1-21);
“ and receiving the confirmation code signed by the external private key of the mobile device, and verifying the confirmation code with an [external public key] corresponding to the external private key, wherein the public key certificate is issued when the verification of the confirmation code is successful” (Fig. 5A: Step 525, the Smart Card 205 i.e., the “external security chip” calculates AKA response with a private key; and Col 7: lines 21-25; Note: AKA protocol involve use of a shared secret session key for data communication/authentication),
“and then the public key certificate is sent to the mobile device” (Fig. 5B: Step 540, the mobile device receives certificate authority signed digital certificate; and Col 7: lines 45-64, the certificate includes the public key and name or identity to whom the certificate was issued among other things).
But de Andrada to specially disclose a secure module having a public/private key pair used in authentication of confirmation code/certificate signing request.
However, Dutta discloses a secure module having a public/private key pair used in authentication of confirmation code/certificate signing request (see, Dutta, Fig. 5 and Para 0144: a secure element with asymmetric cryptographic operation ability and sings the certificate signing request using the private of the secure element; and Para 0101-0109).
It would have been obvious to an ordinary person skilled in the art before the effective filing date of the claimed invention to employ the teachings of a secure module having a public/private key pair used in authentication of confirmation code/certificate signing request of Dutta to the Biometric PKI Authentication of de Andrada to create a system where the secure element help authenticate a user by signing certificate request and the ordinary person skilled in the art would have been motivated to combine to authenticated communication (Dutta, Para 0101-0109).
Regarding claim 10, in view of claim 9, de Andrada discloses “wherein the certificate signing request has been signed by the built-in private key before the mobile device sends the certificate signing request to the certificate authority server” (Fig. 5A: Step 505, Mobile device generates certificate signing request (CSR) including the public key and a Mobile Directory Number (MDN) i.e., “subscriber identity identification information” where the request is signed with the private key; and Col 3:46-49; and Col 6: lines 57-64).
Regarding claim 11, in view of claim 9, de Andrada in view of Dutta disclose “wherein the external security chip includes a public key infrastructure module and a wireless communications module, and the signing and sending of the confirmation code by the mobile device comprise: enabling the public key infrastructure module to sign the confirmation code with the external private key; and enabling the wireless communications module to send the confirmation code to the certificate authority server” (Dutta, Fig. 5 and Para 0144: a secure element with asymmetric cryptographic operation ability and sings the certificate signing request using the private of the secure element; and Para 0101-0109).
Regarding claim 12, in view of claim 9, de Andrada in view of Dutta disclose “wherein the external security chip includes a public key infrastructure module, the external security chip supports a wireless communications protocol or is disposed in a carrier supporting the wireless communications protocol, and the signing of the confirmation code comprises: sending an instruction via the wireless communications protocol, so that the public key infrastructure module uses the external private key to sign the confirmation code” (Dutta, Fig. 5 and Para 0144: a secure element with asymmetric cryptographic operation ability and sings the certificate signing request using the private of the secure element; and Para 0101-0109).
Regarding claim 13, in view of claim 9, de Andrada discloses “wherein the mobile device further performs: storing the public key certificate in a password-protected area of an operating system of the mobile device” (Fig. 1: Mobile Device 105 i.e., a “mobile device” with a Key Store 150 i.e. , a “built-in security chip” stored the public key certificate).
Regarding claim 14, in view of claim 9, de Andrada discloses “wherein the confirmation code is generated according to the certificate signing request and a random number” (see rejection of claim 6).
Regarding claim 15, in view of claim 9, de Andrada in view of Dutta disclose “wherein the verification of the confirmation code by the certificate authority server comprises: obtaining the external public key corresponding to the external private key from a plurality of public keys of a plurality of subscribers according to the subscriber identity identification information to verify the confirmation code” (Dutta, Fig. 5 and Para 0144: a secure element with asymmetric cryptographic operation ability and sings the certificate signing request using the private of the secure element; and Para 0101-0109).
Regarding claim 16, in view of claim 9, de Andrada discloses “wherein the certificate authority server further performs: not issuing and not sending the public key certificate if the verification of the confirmation code fails” (Col 7: lines 48-57, certificate is only issued when AKA response is validated).
Relevant Prior Arts
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rohlwing et al. (US 20230224293 A1) discloses:
[Abstract] Techniques for managing secure communication certificates for medical devices in a clinical environment are provided. A short-lived, limited-use token may be uniquely assigned to a medical device. The medical device can self-provision a secret key and corresponding public key based on a unique identifier in the token. The medical device generates a certificate signing request (“CSR”) that includes the public key, and sends the CSR and the token to a verification system that serves as an intermediary between medical devices and a certificate authority. The intermediary may only send the CSR to the certificate authority (“CA”) for a certificate if the intermediary is able to validate the token.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 date of this final action.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDULLAH ALMAMUN whose telephone number is (571) 270-3392. The examiner can normally be reached on 8 AM - 5 PM.
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, Lynn Feild can be reached on (571) 272-2092. 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.
/ABDULLAH ALMAMUN/Examiner, Art Unit 2431
/LYNN D FEILD/Supervisory Patent Examiner, Art Unit 2431
Prosecution Insights