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 October 02, 2025 in response to the first office action on merit.
Remarks
Pending claims for reconsideration are claims 1-16.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on October 02, 2025 was filed after the mailing date of the application 18/239862 on August 30, 2023 . The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Response to Arguments
Applicant’s arguments filed on October 02, 2025 have been fully considered and they are persuasive, and the prosecution is reopened.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-2, and 4 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by de Andrada et al. (U.S. Patent Publication No.: US 9,692,603 B2 / or “de Andrada” 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” (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 in 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).
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 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).
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 3, and 5-16 are rejected under 35 U.S.C. 103 as being unpatentable over de Andrada in view of Kumar et al. (U.S. Patent Application Publication No.: US 2019/0163912 A1 / or “Kumar” hereinafter).
Regarding claim 3, in view of claim 1, de Andrada discloses a mobile device using the public/private key pair to request public key certificate from a certificate authority (de Andrada: Abstract).
But de Andrada to specially disclose a secure module having a public key infrastructure module and signing confirmation code using the private key.
However, Kumar discloses “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” (Kumar, Para 0062: a secure element with PKI and sings the certificate signing request using the private of the secure element; and Para 0066).
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 key infrastructure module and signing confirmation code using the private key of Kumar to the Biometric PKI Authentication of de Andrada to create a system where the secure element help authenticate a user using PKI and the ordinary person skilled in the art would have been motivated to combine to proof a passion of an identity (Kumar, Para 0053).
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 in an external security chip of the mobile device” (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 authentication of confirmation code.
However, Kumar discloses a secure module having a public/private key pair used authentication of confirmation code (see, Kumar, Para 0062: a secure element with PKI and sings the certificate signing request using the private of the secure element; and Para 0066).
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 authentication of confirmation code of Kumar to the Biometric PKI Authentication of de Andrada to create a system where the secure element help authenticate a user using PKI and the ordinary person skilled in the art would have been motivated to combine to proof a passion of an identity (Kumar, Para 0053).
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 Kumar 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” (Kumar, Para 0062: a secure element with PKI and sings the certificate signing request using the private of the secure element; and Para 0066).
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” (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” ((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 authentication of confirmation code.
However, Kumar discloses a secure module having a public/private key pair used authentication of confirmation code (see, Kumar, Para 0062: a secure element with PKI and sings the certificate signing request using the private of the secure element; and Para 0066).
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 authentication of confirmation code of Kumar to the Biometric PKI Authentication of de Andrada to create a system where the secure element help authenticate a user using PKI and the ordinary person skilled in the art would have been motivated to combine to proof a passion of an identity (Kumar, Para 0053).
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 Kumar 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” (Kumar, Para 0062: a secure element with PKI and sings the certificate signing request using the private of the secure element; and Para 0066).
Regarding claim 12, in view of claim 9, de Andrada in view of Kumar 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” (Kumar, Para 0062: a secure element with PKI and sings the certificate signing request using the private of the secure element; and Para 0066).
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 Kumar 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” (Kumar, Para 0062: a secure element with PKI and sings the certificate signing request using the private of the secure element; and Para 0066).
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.
Frank L Wu (US 10270587 B1) discloses “….the mobile application may use the private key of the mobile device to generate a certificate-signing request to obtain a digital certificate, which may consist of an activation code that was delivered to the card owner either by postal service or online, the public key of the mobile device, and the IMSI number and phone number of the mobile device, from the card issuer, or if the mobile device is new or if the mobile device owner wants to renew all certificates, the mobile application may request certificates for each of the owner's cards; and the request is sent to the card issuer” (Wu, Col 13: lines42-52).
Sykor et al. (U.S. Patent No.: US 10,484,172 B2) discloses “…Key generator 420, in one embodiment, is executable to generate key pairs having a respective public key 422 and a respective private key 424. In the illustrated embodiment, key generator 420 generates a key pair in response to receiving a certified key request 142 via mailbox 320. Although a single request 142 is shown, in other embodiments, key generator 420 may receive separate requests for key generation and certification—e.g., a first request from an application 132 to create a key pair for the application 132 and a second request from the application 132 to obtain a certificate for the key pair…” (Col 15: lines 15-25).
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
/SHIN-HON (ERIC) CHEN/Primary Examiner, Art Unit 2431