Jump to content

Patent Application 17336644 - SECURED PRIVATE CREDENTIAL CERTIFICATE - Rejection

From WikiPatents

Patent Application 17336644 - SECURED PRIVATE CREDENTIAL CERTIFICATE

Title: SECURED PRIVATE CREDENTIAL CERTIFICATE

Application Information

  • Invention Title: SECURED PRIVATE CREDENTIAL CERTIFICATE
  • Application Number: 17336644
  • Submission Date: 2025-05-19T00:00:00.000Z
  • Effective Filing Date: 2021-06-02T00:00:00.000Z
  • Filing Date: 2021-06-02T00:00:00.000Z
  • National Class: 713
  • National Sub-Class: 168000
  • Examiner Employee Number: 94013
  • Art Unit: 2496
  • Tech Center: 2400

Rejection Summary

  • 102 Rejections: 0
  • 103 Rejections: 2

Cited Patents

The following patents were cited in the rejection:

Office Action Text


    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 .

Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection.  Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114.  Applicant's submission filed on 10/07/2024 has been entered.
 
Response to Arguments
In response to 35 USC 103 on pages 11-12, filed 10/07/2024, applicant argues that the prior art fails to teach receiving, at a user device and in response to a request from a credential authority, a signed credential certificate from the credential authority, the signed credential certificate certifying one or more credentials associated with a user of the user device.
Applicant’s argument have been considered but are moot, because the newly recited amendment does not rely on the newly recited reference being applied to the prior rejection of record or any teaching or matter specifically challenged in the argument.

In response to 35 USC 103 on pages 12-14, filed 10/07/2024, applicant argues that the prior art fails to teach receiving, at a first device, a certificate presented from a second device, wherein the certificate was obtained from a third entity by a particular user.
The Examiner does not concede. Avetisov teaches “receiving, at a first device, a certificate presented from a second device, wherein the certificate was obtained from a third entity by a particular user”.  Avetisov discloses “[0068] and Figs. 3A, 6, 7, 8, 11B,  “the computing environment 100A may include a mobile device 101 , a client device 135 , a relaying party 145 , and an authentication server 155.” Avetisov [ 0419 ] In some embodiments, process 800 ( e.g., as described in more detail with reference to FIG . 8 ) may authenticate a user of a mobile device 101 to access a relying device 140 ( e.g. , to which the mobile device is registered under process 700 ) by a mobile initiated login . Avetisov [0420]… “However , in many cases , a user may login to a relying device 140 by other means , such as by entering credentials into the relying device , optionally with out-of-band authentication by the mobile device. Avetisov [0380], “the mobile device may send the user certificate to the authentication server 155 based on an authentication result determined on the mobile device , which may be subject to challenge by the authentication server 155 or driven by conformance to policy on the mobile device ( which may be verified by the authentication server ) . The authentication server 155 may verify the information received from the mobile device , such as in accordance with techniques described herein , such as on established representations of user credentials , signature verification of received data , and issue a user session in a step 811 based on results of a verification determination . Avetisov [0363] In a step 717 , such as responsive to a session issued by the authentication server to the relying device 140 , the relying device may generate a request to a service 175 , such as a certificate service. Avetisov [0365] In step 719 of the process, the relying device 140 may receive a response from the service 175 , such as a signed certificate or token returned in response to the request 717 , like a user certificate , for user credentials corresponding to a user account which may be accessed on the relying device. [0354-0358]Fig. 8 and Fig. 3A)”. Avetisov indicates three parties. The mobile device (second device) gives a certificate to a relying device (first device) via an authentication server (third entity). The Relying device as seen in Fig. 8 step 717 shows obtaining user credentials from the Auth server which in turn were presented by the mobile device 101 in step 713. Fig. 3A shows that a User credential 331 (associated with a particular user) is associated with the mobile device 101.

In response to 35 USC 103 on page 14, filed 10/07/2024, applicant argues that the prior art fails to wherein the local communication is selected from a group consisting of: display to camera communication; printed images to camera communication; and manual entry of displayed codes.
The Examiner does not concede. Avetisov teaches wherein the local communication is selected from a group consisting of: display to camera communication; printed images to camera communication; and manual entry of displayed codes. Avetisov discloses [0085], “example native applications 125 may interface with (or provide an interface on) one or more different components of the mobile device 101 or communicatively coupled devices, such as fingerprint sensors, image sensors, display of software or interface with hardware keyboards, etc. as well as other types of components or biometric sensor devices operable to obtain corresponding user input types”, Please also see [0086] “user input can include selection of one or more characters or digits on a keyboard (e.g., displayed within an interface on a screen of the device or coupled to the device) and receipt of selected characters or digits, which may correspond to a personal identification number, password, or other keyed input” [0349][0350][0366][0403]. From the interface that provides communication includes manual entry of displayed codes.

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 1-22, 33 and 34 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.
Re. claim 1, 13, 33 and 34; the claims recite “receiving, at a user device and in response to a request from a credential authority, a signed credential certificate from the credential authority”. The claim indicates “in response to”, but there is no claim limitation that the credential authority is positively requesting. Furthermore, it is unclear what the credential authority is requesting. 
Claims 2-12, 14-22 fall together accordingly as they do not cure the deficiencies of the independent claims.

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.

Claims 1-22 and 33-34 rejected under 35 U.S.C. 103 as being unpatentable over Avetisov (US 20210044976) in view of Shockley et al. (US 11363005, hereinafter Shockley) and in further view of Krahn (US 9692599, hereinafter Krahn).
Re. claim 1, Avetisov discloses a method, comprising: receiving, at a user device, a signed credential certificate from the credential authority, the signed credential certificate certifying one or more credentials associated with a user of the user device (Avetisov [0237], “…In some embodiments, the authentication server 155 acts as a certificate authority and generates certificates for users… For example , the authentication server 155 may store a root certificate … and generate user digital certificates responsive to requests for distribution based in part on the root certificate . Thus , for example , a user digital certificate may be considered valid by virtual of its generation by the authentication server 155 for use within the identity management system and a user providing ownership of a Net ID 271 also proves ownership of a valid digital certificate authorizing the user to use the system.” Avetisov [ 0172 ], …“In various embodiments , an authentication server 155 may verify access requests received from a mobile device 101 , such as by verifying whether the access request complies with a policy , and which may include verification of representations of credentials stored by the user device , or other data , like certificates , such as by signature verification , where data is signed by a private key , or signature key , maintained within a TEE 103 of the mobile device 101 of the user . The authenticators , like representations , certificates , public key or signature verification key by which data signed with a corresponding private key stored within a TEE 103 may be verified , and the like , may be established during a registration process and may comply with techniques implemented by the authentication server to protect such authenticators in addition to compliance with one or more other services corresponding to the relying device. Avetisov [0174], …”supply credentials … which may be a representation of credentials … and may include a certificate or representation of a certificate”…); causing, by the user device, the signed credential certificate to be stored on a storage server in a format that no device other than the user device is able to read the signed credential certificate (Avetisov [0367] and Fig. 1A, “The authentication server 155 may persist data received from the relying device 140 to the mobile device 101. For example, the authentication server 155 may transmit the user credentials to the mobile device 101, along with offline values. The authentication server 155 may transmit a policy to the mobile device 101, which may specify one or more rules governing user access to the relying device to which the mobile device registered. The above information may be encrypted, such as by a key of a key-pair to which the TEE has access to the other key of the pair and by which the information may be decrypted. In some embodiments, the key may be a shared key. In either instance, data transmitted to the mobile device 101 may be encrypted, and the mobile device may obtain unencrypted data by processing the encrypted data in accordance with an encryption protocol, such as within the TEE of the mobile device, which may securely store a key by which the encrypted data may be decrypted.” Avetisov [0237], “…In some embodiments, the authentication server 155 acts as a certificate authority and generates certificates for users… For example , the authentication server 155 may store a root certificate … and generate user digital certificates responsive to requests for distribution based in part on the root certificate.” Avetisov [0174], …”supply credentials … which may be a representation of credentials … and may include a certificate or representation of a certificate”… Fig. 1A); establishing, by the user device, a communication with a questioning device inquiring about the one or more credentials associated with the user (Avetisov [0039] Authentication of a user that initiates an authentication process on a mobile device may be subject to compliance with one or more policies . A policy may specify one or more rules which users attempting to authenticate must satisfy ( e.g. , via their mobile device ) to successfully authenticate . For example , the mobile device may receive a policy specifying one or more rules with which the user must comply to authenticate and enforce those rules to obtain or generate data for determination of an authentication result ( e.g. , by the mobile device or other entity , like a server or a relying device ) . Different relying devices and different web based service to which a user may authenticate via the mobile device may be subject to different policies. Avetisov [0043], “Some embodiments may expose interfaces by which an entity may authenticate user access to an established identity. For example, the entity may request, via one of the interfaces, authentication of the user. The request may include information operable to identify a record of an established identity. The request may also include user supplied proof of secret knowledge for verification of user access to the established identity.”).
Avetisov do not explicitly teach but Shockley teaches causing, by the user device, the signed credential certificate to be stored on a cloud- based storage server in a format that no device other than the user device is able to read the signed credential certificate (Shockley Fig. 3, Col. 10, ll. 44-50, “FIG . 3 illustrates an example block diagram of a typical storage server environment 300 , where a source device 310 is trying to send source data 315 to a storage server 320 , which would then send the data to a recipient device 330.” Shockley, Col. 64, ll. 58-59, “user device , the storage server may comprise a cloud-based server separate from a transaction entity configured to…”); establishing, by the user device, a conversion key for the questioning device based on a public key of the questioning device (Shockley Col. 16, ll. 5-16, “According to the techniques herein , the source device 410 also establishes a “ recipient - based rekeying key ” 418 through an encrypting combination of a source decryption key 412 ( e.g. , private key ) of the source device and recipient public key 431 of a particular recipient device 430 In particular , and as shown in FIG . 6B , the source device uses its decryption key 412 ( “ Src Pri ” ) to encrypt the recipient public key 431 ( “ Rcpt Pub ” ) ( though as mentioned above , the same result would essentially occur by encrypting the Src Pri with the Rcpt Pub ) , and creates the recipient based rekeying key 418 ( “ Rcpt - Bsd Rekey Key ' ) , accordingly : Src Pri (4 12 ) * Rcpt Pub (4 31 ) = > Rept- Bsd Rekey Key”); and sending, from the user device, the conversion key to the storage server (Shockley Col. 13, ll. 25-45, “In particular , in one embodiment , a storage server may obtain source - encrypted source data from a source device where the source - encrypted source data comprises source data encrypted by the source device with a source encryption key of the source device ( e.g. , a source public key ). The storage server stores the data , and is notably unable to decrypt the source - encrypted source data.”), causing the storage server to i) convert, based on the conversion key, the signed credential certificate into a format readable only by the questioning device based on a private key of the questioning device (Shockley Col 18, ll. 27-56, “In response to the request 550 ( or internal triggering ), the storage server 420 may request the recipient - based rekeying key 418 … ( and may share the recipient device's public key 431 …too ). Regardless , once the storage server has the recipient - based rekeying key 418 from the source device …, and also the source - encrypted source data 417 from the source device (which , notably , may have been received contemporaneously with the rekeying key 418, thus also possibly contemporaneously with the request or prior to obtaining the request ), the storage server may , according to the techniques herein, re-encrypt the source – encrypted source data 417 with the recipient-based rekeying key 418 particular, the re-encrypting results in the source data 415 being encrypted with the recipient public key 431 of the particular recipient device 430, i.e., " recipient-based encrypted source data " 427 ( “ Rcpt - Bsd Encrypt Src Data ” shown below in Eq . 7… Note that the storage server 420 is still unable to decrypt the source data encrypted with the recipient public key ( i.e. recipient - based encrypted source data 427 ), since only the particular recipient device can do that with its private key); and ii) send the signed credential certificate in the format readable only by the questioning device to the questioning device (Shockley Col 18, ll. 64-67, “… the storage server may now send the recipient - based encrypted source data 427 to the particular recipient device 430.”).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by Avetisov to include causing, by the user device, the signed credential certificate to be stored on a cloud- based storage server in a format that no device other than the user device is able to read the signed credential certificate; establishing, by the user device, a conversion key for the questioning device based on a public key of the questioning device; and sending, from the user device, the conversion key to the storage server, causing the storage server to i) convert, based on the conversion key, the signed credential certificate into a format readable only by the questioning device based on a private key of the questioning device; and ii) send the signed credential certificate in the format readable only by the questioning device to the questioning device as disclosed by Shockley. One of ordinary skill in the art would have been motivated for the purpose of authenticate without revealing any secret identifying information to third-party devices. Such an addition uses known methods (using a proxy re-encryption key) to produce a predictable result (sending encrypted messages via a proxy that is unable to decrypt the message but can pass the message on to a third party who can decrypt after the transformation key is applied). Such an addition uses known methods (cloud computing) to produce a predictable result (having the ability to outsource and scale computation resources quickly and efficiently).  
Although Avetisov teaches receiving signed credential certificate but the combination of Avetisov-Shockley do not explicitly teach but Krahn teaches receiving, at a user device and in response to a request from a credential authority, a signed credential certificate from the credential authority (Krahn teaches endorsement engine 132 can provide, in a request for an attestation identity credential, specialized endorsement credential 148 to certificate authority server 110, and receive, from certificate authority server 110, attestation identity credential 144 [Col 8 lines 49-62]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by the combination of Avetisov-Schockley to include receiving, at a user device and in response to a request from a credential authority, a signed credential certificate from the credential authority as disclosed by Shockley. One of ordinary skill in the art would have been motivated for the purpose of validate authenticity (Krahn [Col 8 lines 49-62]).  

Re. claim 2, Avetisov, Shockley and Krahn teach the method as in claim 1. In addition Avetisov teaches: further comprising: encrypting, by the user device, the signed credential certificate with a user encryption key of the user device into the format that no device other than the user device is able to read, hereinafter a user-encrypted signed credential certificate, (Avetisov [0380] and Fig. 1A, “As described above , successful authentication of the user on the mobile device 101 may include user authentication within a TEE of the mobile device to release a user certificate corresponding to a user account for logging into the relying device 140. The user cert may be encrypted , or stored within a secure memory of the TEE of the user device such that the CEE cannot access the certificate in unencrypted form . Additionally , singing of the user certificate may be performed with the TEE based on a private key or signature key stored within a secure memory of the TEE which the CEE may not access , and the TEE may not release the private key or signature key”)
In addition Shockley teaches:
wherein the conversion key comprises an encrypting combination of a user decryption key of the user device and a public key of the questioning device, and (Shockley Col. 16, ll. 47-61, “”key 418 , to decrypt the data , as described below . Addition ally , since the recipient - based rekeying key 418 is a com bination of the source device's private key ( or other decryption key ) and the recipient device's public key , the only data transformation that the storage server 420 ( e.g. , if hacked ) , or any other device for that matter , could perform on the recipient - based rekeying key 418 is based on knowing the source device's public key 411 , which as shown in Eq . 6b below , merely would result in the publicly known public key of the recipient : Rept - Bsd Rekey Key ( 418 ) * Src Pub ( 411 ) = ( Src Pri ( 412 ) * Rcpt Pub ( 431 ) ) * Src Pub ( 411 ) = ( Src Pri ( 412 ) * ( Src Pub ( 411 ) * Rcpt Pub ( 431 ) = ( 1 ) * Rcpt Pub ( 431 ) = > Rcpt Pub ( 431 ) Eq . 6b .)
wherein the conversion key causes the storage server to convert the signed credential certificate into a format readable only by the questioning device by re-encrypting the user-encrypted signed credential certificate with the conversion key, ( Shockley Col. 13, ll. 20-25, “the storage server can convert the source data into a format readable only by the particular recipient device based on the conversion key, and sends the source data in the format readable only by the particular recipient device to the particular recipient device, accordingly.”)
wherein the questioning device is caused to decrypt the signed credential certificate in the format readable only by the questioning device using a private key of the questioning device to obtain the signed credential certificate. (Shockley Col. 13 ll. 50-53, “encrypted source data using a recipient private key of the particular recipient device to obtain the source data , accordingly.”)
Avetisov and Shockley are in the similar field of endeavor related to the technology of secure authentication.  It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Shockley into the invention of Avetisov for the purpose of being able to authenticate without revealing any secret identifying information. Based on the KSR v. TELEFLEX rationale, such an addition uses known methods (using a re-encryption key process) to produce a predictable result (allowing third-party attestation while keeping personal information secret).  
Re. claim 3, Avetisov, Shockley and Krahn teach the method as in claim 1. In addition Shockley teaches: wherein the signed credential certificate comprises the one or more credentials encrypted with an encryption key of the credential authority, and wherein the questioning device validates the signed credential certificate using a decryption key of the credential authority. (Shockley Col. 36, 12-20, In one embodiment , similar to digital signature techniques , the attestation server 1510 signs its verification message ( signing the signed certificate ) by encrypting the verification message ( attestation contents 1565 ) by its own private key ( attestation server private key 1512 ) . This message can then be decrypted by any verifying recipient device with knowledge of public key 1511 of the attestation server which is known to everyone as it is public ).”) 
Avetisov and Shockley are in the similar field of endeavor related to the technology of secure authentication.  It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Shockley into the invention of Avetisov for the purpose of being able to authenticate without revealing any secret identifying information. Based on the KSR v. TELEFLEX rationale, such an addition uses known methods (digital signature) to produce a predictable result (providing non-repudiation of signed messages).   
Re. claim 4, Avetisov, Shockley and Krahn teach the method as in claim 1, In addition Shockley teaches:
wherein the one or more credentials associated with the user are selected from a group consisting of: health information; vaccination information; testing results; application results; and reports. (Shockley Col. 35 l. 65-Col. 36 l.1, “ … the certificate may be anything from a simple verified ” indication , an attestation score , a report of what is being attested to ( e.g. , “ this certifies that user ID # 12345 has acceptably provided their identity on this date ”)
Avetisov and Shockley are in the similar field of endeavor related to the technology of secure authentication.  It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the report into the credential as described by Shockley into the credential of Avetisov. Such an addition uses known methods (adding specific attribute information to a credential) to produce a predictable result (uniquely identifying credentials based on attributes).   
Re. claim 5, Avetisov, Shockley and Krahn teach the method as in claim 1, in addition Avetisov teaches: further comprising: authenticating the user at the user device prior to receiving the signed credential certificate from the credential authority. (Avetisov [0394], “[ 0394 ] In a step 903 , a user may elect to login to the relying device 140 on a mobile device 101. Examples of step 903 may occur as described with reference to step 803 in FIG . 8. For example , the user may navigate a user interface of an authentication application executing on the mobile device 101 and select a relying device with which the mobile device is registered for mobile initiated authentications . In turn , the mobile device 101 may transmit an access request corresponding to the selected relying device 140 to the authentication server 155 . [ 0395 ] In some cases , the authentication server 155 may be available to the mobile device 101 but not to the relying device 140. Accordingly , in some cases , mobile device and authentication server 155 communicate some information as described in FIG . 8 , but without relying device 140 participation . In some cases , this may be governed by a policy . In some cases , the authentication server 155 may similarly be unavailable to the mobile device 101 , and authentication may be governed by offline policy ( e.g. , as described in FIG . 9B ) . Thus , for example , step 907A may include operations similar to those described with reference to steps 807 or 809 of FIG . 8 . [ 0396 ] In some embodiments , in a step 903 , the authentication server 155 may transmit information to the mobile device based on the inability of the authentication server to communicate with the relying device 140. For example , the authentication server 155 may return user credentials to the user ( optionally signed ) , a notification , or other response “ Avetisov [0309] Figs. 7, 8, 9A and 9B, “ The user may be prompted or otherwise request to input 331 one or more credentials . The input credentials are obtained within the TEE 103 , and the TEE 103 may verify 332 credential input [i.e. authenticating the user]. Representations of the input credentials may be generated, or stored representations of the input credentials the TEE 103 verified 332 according to the input credentials may be output by the TEE.” Avetisov [0401], “In some embodiments , the process of FIG . 9B may occur after a registration process , such as the registration process described with reference to FIG . 7 , or other registration process described herein , or after a mobile device receives offline values . Avetisov [0402], “Thus , for example , step 907A may include at least some operations similar to those described with reference to steps 807 or 809 of FIG . 8 , such as those user authentication operations which are performed within the TEE but in accordance with an offline policy and without communication with the authentication server 155.)
Re. claim 6, Avetisov, Shockley and Krahn teach the method as in claim 1, in addition Avetisov teaches: 
further comprising: authenticating the user at the user device during the communication with the questioning device inquiring about the one or more credentials associated with the user. (Avetisov [0394], “In a step 903 , a user may elect to login to the relying device 140 on a mobile device 101. Examples of step 903 may occur as described with reference to step 803 in FIG . 8. For example , the user may navigate a user interface of an authentication application executing on the mobile device 101 and select a relying device with which the mobile device is registered for mobile initiated authentications . In turn , the mobile device 101 may transmit an access request corresponding to the selected relying device 140 to the authentication server 155 .”)
Re. claim 7, Avetisov, Shockley and Krahn teach the method as in claim 1, in addition Shockley teaches: wherein the signed credential certificate comprises a government authorization for the credential authority. (Shockley 34, ll. 25-30, “In another illustrative embodiment , for instance , the verifying recipient device 1530 may be a government agency requesting attestation of a user's identity information ( within source data 415 ) at the source device , where the government agency device may ( though need not be ) be a particular recipient device 430 , as described above.”)
Avetisov and Shockley are in the similar field of endeavor related to the technology of secure authentication.  It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the government authorization as described by Shockley into the invention of Avetisov. Based on the KSR v. TELEFLEX rationale, such an addition uses known methods (using the methods of proxy re-encryption) to produce a predictable result (have a government actor receive and send information via a third party proxy).   
Re. claim 8, Avetisov, Shockley and Krahn teach the method as in claim 7, in addition Shockley teaches: wherein the questioning device validates the government authorization using a decryption key of a government authority after reading the signed credential certificate.  (Shockley 34, ll. 25-30, “In another illustrative embodiment , for instance , the verifying recipient device 1530 may be a government agency requesting attestation of a user's identity information ( within source data 415 ) at the source device , where the government agency device may ( though need not be ) be a particular recipient device 430 , as described above.”) Shockley Col. 36, 12-20, In one embodiment , similar to digital signature techniques , the attestation server 1510 signs its verification message ( signing the signed certificate ) by encrypting the verification message ( attestation contents 1565 ) by its own private key ( attestation server private key 1512 ) . This message can then be decrypted by any verifying recipient device with knowledge of public key 1511 of the attestation server which is known to everyone as it is public ).”)
Avetisov and Shockley are in the similar field of endeavor related to the technology of secure authentication.  It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate government authorizer acting as an attestation server to authorize a message as described by Shockley into the invention of Avetisov. Such an addition uses known methods (using proxy re-encryption) to produce a predictable result (storing the government authorization on a server where only the government and intended recipient can decrypt it).   
Re. claim 9, Avetisov, Shockley and Krahn teach the method as in claim 1, in addition Avetisov teaches: wherein establishing the communication with the questioning device comprises a co-located local communication. (Avetisov [0225] In some embodiments , the computing environment 200 may include a mobile device 101 , a client device 135 ( “e.g. a primary device in a device pair used in an authentication session by a user ), relying party computing systems like application servers 245 , and an authentication server 155. These components may communicate with one another via a network 121, such as the Internet and various other local area networks.”)
Re. claim 10, Avetisov, Shockley and Krahn teach the method as in claim 9, in addition Avetisov teaches:
wherein the local communication is selected from a group consisting of: display to camera communication; printed images to camera communication; near field communication; Wi-Fi; and manual entry of displayed codes. (Avetisov [0085], “example native applications 125 may interface with (or provide an interface on) one or more different components of the mobile device 101 or communicatively coupled devices, such as fingerprint sensors, image sensors, display of software or interface with hardware keyboards, etc. as well as other types of components or biometric sensor devices operable to obtain corresponding user input types”, [0086] “user input can include selection of one or more characters or digits on a keyboard (e.g., displayed within an interface on a screen of the device or coupled to the device) and receipt of selected characters or digits, which may correspond to a personal identification number, password, or other keyed input”  [0349][0350][0366][0403]). 
Re. claim 11, Avetisov, Shockley and Krahn teach the method as in claim 1, in addition Avetisov teaches: wherein establishing the communication with the questioning device comprises a remote communication. (Avetisov [0065], “ Further , some embodiments may execute a federated identity management client module or application by which different client - side applications coordinate with one another , access authentication - related client - side state , and coordinate with remote computing devices. The computing architecture may further include various collections of servers that expose the various secured resources for which authentication determinations are made . Avetisov [0225 ] In some embodiments , the computing environment 200 may include a mobile device 101 , a client device 135 ( “e.g. a primary device in a device pair used in an authentication session by a user ) , relying party computing systems like application servers 245 , and an authentication server 155. These components may communicate with one another via a network 121 , such as the Internet and various other local area networks.”)
Re. claim 12, Avetisov, Shockley and Krahn teach the method as in claim 1, in addition Avetisov teaches: wherein the questioning device is associated with an enterprise selected from a group consisting of: a building; a structure; a vehicle; a ticket agency; a restaurant; a bar; an entertainment venue; a sport venue; a travel port; a political border entry; a school; a livery transportation vehicle; and a store. (Avetisov [ 0166 ] “In some embodiments , a relying device 140 may be a controller or communicatively coupled to a controller which governs physical user access to areas or functions ( e.g. , valves or machinery or panels ) via electrical signals . Such relying devices may thus control physical access or a function by activation of a given mechanism , like an electro mechanical device , which may include an electromagnet , an electrical motor , a solenoid or other circuit to cause a change in an electromagnetic field to actuate a lock , like driving a pin into or out of a hole , changing a state of an electromagnet adjacent a ferromagnetic plate attached to a door , or the like ( e.g. , to access or secure access to an area or receptacle or otherwise interact with a secure asset - like a switch to turn some device ) . The electro - mechanical device may include one or more hardware elements like a processor , memory , receiver , transmitter , and the like to receive results for authentication . Some electro - mechanical devices may process the results directly by verification of signature , or transmit the result and receive a response , such as from a server . In either instance , the electro - mechanical device may actuate a mechanism based on a received result . In other words , a relying device 140 may be a device within a relatively diverse set of devices , but may generally be a device which users physically access ( e.g. , in person ) or controls physical access of the user ( e.g. , to a room , area , etc. ).
Re. claim 13, Avetisov teaches a method, comprising: establishing, … a communication with a user device, wherein the questioning device is inquiring into one or more credentials associated with a user of the user device (“Avetisov [0346] Fig. 7, “[0363] In a step 717 , such as responsive to a session issued by the authentication server to the relying device 140 , the relying device may generate a request to a service 175 , such as a certificate service. … In step 717 , the request for a certificate may be to an active directory service , or other service which governs credentialing of relying devices , such as user accounts on such relying devices and the like , such as for examples in which a relying device is a workstation or server executing an operating system or modules configured to utilize the respective service .”); receiving, at the questioning device, a signed credential certificate established by the credential authority (Avetisov [0365] In step 719 of the process , the relying device 140 may receive a response from the service 175 , such as a signed certificate or token returned in response to the request 717 , like a user certificate , for user credentials corresponding to a user account which may be accessed on the relying device. Avetisov [0237], “the instructions may cause the relying device 140 to launch an application 110, like a web browser , navigate to a web portal via the web browser , and submit one or more authenticators as credentials 111 to access the web portal , which may be displayed within a browser window or tab . In another example , the instructions may cause the relying device 140 to launch an application requiring a user login and provide the authenticators as credentials 111” Avetisov [0237], “…In some embodiments, the authentication server 155 acts as a certificate authority and generates certificates for users… Avetisov [ 0172 ], …“In various embodiments , an authentication server 155 may verify access requests received from a mobile device 101 , such as by verifying whether the access request complies with a policy , and which may include verification of representations of credentials stored by the user device , or other data , like certificates , such as by signature verification , where data is signed by a private key , or signature key , maintained within a TEE 103 of the mobile device 101 of the user . The authenticators , like representations , certificates , public key or signature verification key by which data signed with a corresponding private key stored within a TEE 103 may be verified , and the like , may be established during a registration process and may comply with techniques implemented by the authentication server to protect such authenticators in addition to compliance with one or more other services corresponding to the relying device. Avetisov [0174], …”supply credentials … which may be a representation of credentials … and may include a certificate or representation of a certificate”…) Examiner submits, authentication server is credential authority that generates signed credentials for users, and such credentials may be sent to the questioning device (relying device).), the signed credential certificate certifying one or more credentials associated with a user of the user device (Avetisov [0365] In step 719 of the process , the relying device 140 may receive a response from the service 175 , such as a signed certificate or token returned in response to the request 717 , like a user certificate , for user credentials corresponding to a user account which may be accessed on the relying device. … [ 0366 ] Additionally , the relying device 140 may generate one or more offline values in accordance with an offline policy received from the authentication server 155 or stored on the relying device 140. Offline policy may provide for use of an offline value for a user login to a relying device 140. Avetisov [0174], …”supply credentials … which may be a representation of credentials … and may include a certificate or representation of a certificate”…).
Avetisov teaches establishing a communication, Avetisove does not explicitly teach but Shockley teaches establishing, by a questioning device, a communication with a user device… (Shockley 34, ll. 25-30, “In another illustrative embodiment , for instance , the verifying recipient device 1530 may be a government agency requesting attestation of a user's identity information ( within source data 415 ) at the source device , where the government agency device may ( though need not be ) be a particular recipient device 430 , as described above.”); providing, by the questioning device, information to cause the user device to establish a conversion key for the questioning device (Shockley Col. 16, ll. 5-16, “According to the techniques herein , the source device 410 also establishes a “ recipient - based rekeying key ” 418 through an encrypting combination of a source decryption key 412 ( e.g. , private key ) of the source device and recipient public key 431 of a particular recipient device 430 In particular , and as shown in FIG . 6B , the source device uses its decryption key 412 ( “ Src Pri ” ) to encrypt the recipient public key 431 ( “ Rcpt Pub ” ) ( though as mentioned above , the same result would essentially occur by encrypting the Src Pri with the Rcpt Pub ) , and creates the recipient based rekeying key 418 ( “ Rcpt - Bsd Rekey Key ' ) , accordingly : Src Pri (4 12 ) * Rcpt Pub (4 31 ) = > Rept- Bsd Rekey Key”); the signed credential certificate being encrypted using a public key of the questioning device and based on the conversion key for the questioning device being used to convert the signed credential certificate from a format that no device other than the user device is able to read into a format readable only by the questioning device (Shockley Col 18, ll. 27-56, “In response to the request 550 ( or internal triggering ) , the storage server 420 may request the recipient - based rekeying key 418 … ( and may share the recipient device's public key 431 …too ) . Regardless , once the storage server has the recipient - based rekeying key 418 from the source device …, and also the source - encrypted source data 417 from the source device ( which , notably , may have been received contemporaneously with the rekeying key 418 , thus also possibly contemporaneously with the request or prior to obtaining the request ) , the storage server may , according to the techniques herein , re-encrypt the source – encrypted source data 417 with the recipient-based rekeying key 418 particular , the re-encrypting results in the source data 415 being encrypted with the recipient public key 431 of the particular recipient device 430 , i.e. , " recipient-based encrypted source data " 427 ( “ Rcpt - Bsd Encrypt Src Data ” shown below in Eq . 7… Note that the storage server 420 is still unable to decrypt the source data encrypted with the recipient public key ( i.e. recipient - based encrypted source data 427 ) , since only the particular recipient device can do that with its private key); and decrypting, by the questioning device and based on a private key of the questioning device, the signed credential certificate in the format readable only by the questioning device to obtain the signed credential certificate (Shockley Col. 35, ll. 37-45, “Once the attestation server 1510 receives the source data encrypted with the attestation server public key ( attestation-server-based encrypted source data 1527 ) from the storage server 420 , then the attestation server applies its private key to obtain and process the user's identity information from the previously encrypted source data ( i.e. , decrypting the attestation - server - based encrypted source data 1527 using an attestation server private key 1512 of the attestation server ) .”).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by Avetisov to include establishing, by a questioning device, a communication with a user device…; providing, by the questioning device, information to cause the user device to establish a conversion key for the questioning device; the signed credential certificate being encrypted using a public key of the questioning device and based on the conversion key for the questioning device being used to convert the signed credential certificate from a format that no device other than the user device is able to read into a format readable only by the questioning device; and decrypting, by the questioning device and based on a private key of the questioning device, the signed credential certificate in the format readable only by the questioning device to obtain the signed credential certificate as disclosed by Shockley. One of ordinary skill in the art would have been motivated for the purpose of being able to authenticate without revealing any secret identifying information to third-party devices. Such an addition uses known methods (using a proxy re-encryption key) to produce a predictable result (sending encrypted messages via a proxy that is unable to decrypt the message but can pass the message on to a third party who can decrypt after the transformation key is applied).  
Although Avetisov teaches receiving signed credential certificate but the combination of Avetisov-Shockley do not explicitly teach but Krahn teaches receiving, at a user device and in response to a request from a credential authority, a signed credential certificate from the credential authority (Krahn teaches endorsement engine 132 can provide, in a request for an attestation identity credential, specialized endorsement credential 148 to certificate authority server 110, and receive, from certificate authority server 110, attestation identity credential 144 [Col 8 lines 49-62]).
Therefore, it would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to modify the method and system disclosed by the combination of Avetisov-Schockley to include receiving, at a user device and in response to a request from a credential authority, a signed credential certificate from the credential authority as disclosed by Shockley. One of ordinary skill in the art would have been motivated for the purpose of validate authenticity (Krahn [Col 8 lines 49-62]).  
Re. claim 14, Avetisov, Shockley and Krahn teach the method as in claim 13, in addition Avetisov teaches: 
wherein the signed credential certificate is stored on a storage server and is encrypted by the user device with a user encryption key of the user device into the format that no device other than the user device is able to read, hereinafter a user-encrypted signed credential certificate, (Avetisov [0367] and Fig. 1A, “The authentication server 155 may persist data received from the relying device 140 to the mobile device 101. For example, the authentication server 155 may transmit the user credentials to the mobile device 101, along with offline values. The authentication server 155 may transmit a policy to the mobile device 101, which may specify one or more rules governing user access to the relying device to which the mobile device registered. The above information may be encrypted, such as by a key of a key-pair to which the TEE has access to the other key of the pair and by which the information may be decrypted. In some embodiments, the key may be a shared key. In either instance, data transmitted to the mobile device 101 may be encrypted, and the mobile device may obtain unencrypted data by processing the encrypted data in accordance with an encryption protocol, such as within the TEE of the mobile device, which may securely store a key by which the encrypted data may be decrypted.” Avetisov [0380] and Fig. 1A, “As described above , successful authentication of the user on the mobile device 101 may include user authentication within a TEE of the mobile device to release a user certificate corresponding to a user account for logging into the relying device 140. The user cert may be encrypted , or stored within a secure memory of the TEE of the user device such that the CEE cannot access the certificate in unencrypted form . Additionally , singing of the user certificate may be performed with the TEE based on a private key or signature key stored within a secure memory of the TEE which the CEE may not access , and the TEE may not release the private key or signature key”) Examiner submits that encrypted certificate credentials with the user key pair is only readable by the user—in this case the TEE  (See Fig. 1A) is part of the user system. Furthermore, such credentials may be stored on the authentication server (i.e. a storage server).
In addition Shockley teaches: 
wherein the conversion key comprises an encrypting combination of a user decryption key of the user device and a public key of the questioning device, (Shockley Col. 16, ll. 47-61, “”key 418 , to decrypt the data , as described below . Addition ally , since the recipient - based rekeying key 418 is a com bination of the source device's private key ( or other decryption key ) and the recipient device's public key , the only data transformation that the storage server 420 ( e.g. , if hacked ) , or any other device for that matter , could perform on the recipient - based rekeying key 418 is based on knowing the source device's public key 411 , which as shown in Eq . 6b below , merely would result in the publicly known public key of the recipient : Rept - Bsd Rekey Key ( 418 ) * Src Pub ( 411 ) = ( Src Pri ( 412 ) * Rcpt Pub ( 431 ) ) * Src Pub ( 411 ) = ( Src Pri ( 412 ) * ( Src Pub ( 411 ) * Rcpt Pub ( 431 ) = ( 1 ) * Rcpt Pub ( 431 ) = > Rcpt Pub ( 431 ) Eq . 6b .)
 and wherein the conversion key causes the storage server to convert the signed credential certificate into a format readable only by the questioning device by re-encrypting the user-encrypted signed credential certificate with the conversion key,  ( Shockley Col. 13, ll. 20-25, “the storage server can convert the source data into a format readable only by the particular recipient device based on the conversion key, and sends the source data in the format readable only by the particular recipient device to the particular recipient device, accordingly.”)
the method further comprising: decrypting, by the questioning device, the signed credential certificate in the format readable only by the questioning device using a private key of the questioning device to obtain the signed credential certificate. (Shockley Col. 13 ll. 50-53, “encrypted source data using a recipient private key of the particular recipient device to obtain the source data , accordingly.”)
Avetisov and Shockley are in the similar field of endeavor related to the technology of secure authentication.  It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Shockley into the invention of Avetisov for the purpose of being able to authenticate without revealing any secret identifying information. Based on the KSR v. TELEFLEX rationale, such an addition uses known methods (using a re-encryption key process) to produce a predictable result (allowing third-party attestation while keeping personal information secret).  
Re. claim 15, The rejection of claim 13 is incorporated. In addition, claim 15 is a method claim reciting limitations that are similar to the ones of claim 3. Therefore, claim 15 is rejected with the same rationale and motivation as applied in claim 3 above.
Re. claim 16, The rejection of claim 13 is incorporated. In addition, claim 16 is a method claim reciting limitations that are similar to the ones of claim 4. Therefore, claim 16 is rejected with the same rationale and motivation as applied in claim 4 above.
Re. claim 17, The rejection of claim 13 is incorporated. In addition, claim 17 is a method claim reciting limitations that are similar to the ones of claim 5. Therefore, claim 17 is rejected with the same rationale and motivation as applied in claim 5 above.
Re. claim 18, The rejection of claim 13 is incorporated. In addition, claim 18 is a method claim reciting limitations that are similar to the ones of claim 7. Therefore, claim 18 is rejected with the same rationale and motivation as applied in claim 7 above.
Re. claim 19, The rejection of claim 18 is incorporated. In addition, claim 19 is a method claim reciting limitations that are similar to the ones of claim 8. Therefore, claim 19 is rejected with the same rationale and motivation as applied in claim 8 above.
Re. claim 20, The rejection of claim 13 is incorporated. In addition, claim 20 is a method claim reciting limitations that are similar to the ones of claim 9. Therefore, claim 20 is rejected with the same rationale and motivation as applied in claim 9 above.
Re. claim 21, The rejection of claim 20 is incorporated. In addition, claim 21 is a method claim reciting limitations that are similar to the ones of claim 10. Therefore, claim 21 is rejected with the same rationale and motivation as applied in claim 10 above.
Re. claim 22, The rejection of claim 18 is incorporated. In addition, claim 19 is a method claim reciting limitations that are similar to the ones of claim 8. Therefore, claim 19 is rejected with the same rationale and motivation as applied in claim 8 above.
Re. claim 33, Avetisov discloses a non-transitory computer readable medium reciting the same limitations above in claim 1.
In addition Avetisov teaches the non-transitory computer readable medium (Avetisov [0415] “The mobile device 101 may execute the authentication application , such as by loading the authentication application in a memory of the mobile device and executing the authentication application by a processor of the mobile device . In some embodiments , a memory and a processor of the mobile device 101 may be configured for the execution of applications within a client execution environment ( CEE ) , which may be isolated from a trusted execution environment ( TEE ) of the mobile device . The TEE may include a secure memory and co - processor not accessible by applications or processes executing within the CEE . For example , an application executing within the CEE may be required to securely communicate with an interface of the TEE to request data from and request processing of data within the TEE , and the interface may respond to various requests based on verification of certain criteria .”)
Therefore, claim 33  is rejected with the same rationale and motivation as applied in claim 1  above.
Re. claim 34, it is a computer readable medium claim that encompasses limitations similar to those of method claim 13. Therefore, claim 34 is rejected with the same motivation and rationale as applied against claim 13.

Claims 23-32 and 35 are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov (US 20210044976) in view of Shockley et al. (US 11363005, hereinafter Shockley).
Re. claim 23, Avestisov discloses a method, comprising: receiving, at a first device, a certificate presented from a second device, wherein the certificate was obtained from a third entity by a particular user (Avetisov [0068] and Figs. 3A, 6, 7, 8, 11B,  “the computing environment 100A may include a mobile device 101 , a client device 135 , a relaying party 145 , and an authentication server 155.” Avetisov [ 0419 ] In some embodiments, process 800 ( e.g., as described in more detail with reference to FIG . 8 ) may authenticate a user of a mobile device 101 to access a relying device 140 ( e.g. , to which the mobile device is registered under process 700 ) by a mobile initiated login . Avetisov [0420]… “However , in many cases , a user may login to a relying device 140 by other means , such as by entering credentials into the relying device , optionally with out-of-band authentication by the mobile device. Avetisov [0380], “the mobile device may send the user certificate to the authentication server 155 based on an authentication result determined on the mobile device , which may be subject to challenge by the authentication server 155 or driven by conformance to policy on the mobile device ( which may be verified by the authentication server ) . The authentication server 155 may verify the information received from the mobile device , such as in accordance with techniques described herein , such as on established representations of user credentials , signature verification of received data , and issue a user session in a step 811 based on results of a verification determination . Avetisov [0363] In a step 717 , such as responsive to a session issued by the authentication server to the relying device 140 , the relying device may generate a request to a service 175 , such as a certificate service. Avetisov [0365] In step 719 of the process, the relying device 140 may receive a response from the service 175 , such as a signed certificate or token returned in response to the request 717 , like a user certificate , for user credentials corresponding to a user account which may be accessed on the relying device. [0354-0358]Fig. 8 and Fig. 3A).
Avetisov does not explicitly teach but Shockley teaches confirming, by the first device, that a present user of the second device is the particular user that obtained the certificate from the third entity, without determining an identity of the present user and the particular user (Shockley Col. 41, ll. 50-55, of the source - encrypted source data 417. ) The IDV provider 2170 can then accredit / attest to the user's approved identity ( or may disapprove it ) , and creates a signed certificate as described above for consumption by the bank ( partner 2140 ) to allow the bank to open the account without the bank ever knowing the user's real - life identity or related PII…”); and confirming, by the first device, that the third entity is an issuer of the certificate, without determining the identity of the present user and the particular user, and without disclosing the identity of the first device to the third entity (Shockley Col. 48, ll. 43-49, Then , in step 2345 , the storage server applies the attestation server re-encryption key 1533 to the original signed certificate 1560_t to generate an updated signed certificate 1560_1 + 1that is signed with the updated attestation server private key 1512_t + 1 ( for verification using the updated attestation server public key 1511_t + 1 , below ).).
Avetisov and Shockley are in the similar field of endeavor related to the technology of secure authentication.  It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Shockley into the invention of Avetisov for the purpose of being able to authenticate without revealing any secret identifying information. Based on the KSR v. TELEFLEX rationale, such an addition uses known methods (using a re-encryption key process) to produce a predictable result (allowing third-party attestation while keeping personal information secret).  
Re. claim 24, Avetisov and Shockley teach the method as in claim 23, in addition Shockley teaches: 
further comprising: confirming, by the first device, that the certificate contains a proof that the third entity is certified by a fourth party to issue the certificate. (Shockley Col. 41, ll. 50-55, of the source - encrypted source data 417. ) The IDV provider 2170 can then accredit / attest to the user's approved identity ( or may disapprove it ) , and creates a signed certificate as described above for consumption by the bank ( partner 2140 ) to allow the bank to open the account without the bank ever knowing the user's real - life identity or related PII…”)
In addition to the user/storage server/bank, the IDV provider is a delegate of the bank and a “fourth” party to the transaction. 
Avetisov and Shockley are in the similar field of endeavor related to the technology of secure authentication.  It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Shockley into the invention of Avetisov for the purpose of being able to authenticate without revealing any secret identifying information. Based on the KSR v. TELEFLEX rationale, such an addition uses known methods (using a flexible validation of an entity) to produce a predictable result (being able to validate an entity via any other pathway between devices).   
Re. claim 25, Avetisov and Shockley teach the method as in claim 23, in addition Shockley teaches: 
further comprising: providing information, prior to receiving the certificate, to cause the second device to establish a conversion key for the first device, (Shockley Col. 16, ll. 5-16, “According to the techniques herein , the source device 410 also establishes a “ recipient - based rekeying key ” 418 through an encrypting combination of a source decryption key 412 ( e.g. , private key ) of the source device and recipient public key 431 of a particular recipient device 430 In particular , and as shown in FIG . 6B , the source device uses its decryption key 412 ( “ Src Pri ” ) to encrypt the recipient public key 431 ( “ Rcpt Pub ” ) ( though as mentioned above , the same result would essentially occur by encrypting the Src Pri with the Rcpt Pub ) , and creates the recipient based rekeying key 418 ( “ Rcpt - Bsd Rekey Key ' ) , accordingly : Src Pri (4 12 ) * Rcpt Pub (4 31 ) = > Rept- Bsd Rekey Key”) The information provided is the public key of the Recipient Device, and it is then used to create the conversion key (re-encryption key). 
wherein the received certificate is encrypted based on the conversion key for the first device being used to convert the certificate from a format that no device other than the second device is able to read into a format readable only by the first device; (Shockley Fig. 3, Col. 10, ll. 44-50, “FIG . 3 illustrates an example block diagram of a typical storage server environment 300 , where a source device 310 is trying to send source data 315 to a storage server 320 , which would then send the data to a recipient device 330.” Shockley, Col. 64, ll. 58-59, “user device , the storage server may comprise a cloud-based server separate from a transaction entity configured to…”)  
wherein confirming that the present user of the second device is the particular user that obtained the certificate from the third entity and confirming that the third entity is the issuer of the certificate, are based on decrypting the certificate in the format readable only by the first device to obtain a signed certificate issued by the third entity for the particular user, without determining the identity of the present user and the particular user. (Shockley Col. 41, ll. 50-55, of the source - encrypted source data 417. ) The IDV provider 2170 can then accredit / attest to the user's approved identity ( or may disapprove it ) , and creates a signed certificate as described above for consumption by the bank ( partner 2140 ) to allow the bank to open the account without the bank ever knowing the user's real - life identity or related PII…”)
Avetisov and Shockley are in the similar field of endeavor related to the technology of secure authentication.  It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Shockley into the invention of Avetisov for the purpose of being able to authenticate without revealing any secret identifying information. Based on the KSR v. TELEFLEX rationale, such an addition uses known methods (using a re-encryption key process) to produce a predictable result (allowing attestation while keeping personal information secret).   
Re. claim 26, The rejection of claim 25 is incorporated. In addition, claim 26 is a method claim reciting limitations that are similar to the ones of claim 3. Therefore, claim 26 is rejected with the same rationale and motivation as applied in claim 3 above.
Re. claim 27, The rejection of claim 23 is incorporated. In addition, claim 27 is a method claim reciting limitations that are similar to the ones of claim 4. Therefore, claim 27 is rejected with the same rationale and motivation as applied in claim 4 above.
Re. claim 28, The rejection of claim 23 is incorporated. In addition, claim 28 is a method claim reciting limitations that are similar to the ones of claim 9. Therefore, claim 28 is rejected with the same rationale and motivation as applied in claim 9 above.
Re. claim 29, The rejection of claim 28 is incorporated. In addition, claim 29 is a method claim reciting limitations that are similar to the ones of claim 10. Therefore, claim 29 is rejected with the same rationale and motivation as applied in claim 10 above.
Re. claim 30, The rejection of claim 23 is incorporated. In addition, claim 30 is a method claim reciting limitations that are similar to the ones of claim 11. Therefore, claim 30 is rejected with the same rationale and motivation as applied in claim 11 above.
Re. claim 31, Avetisov and Shockley teach the method as in claim 23, in addition Shockley teaches: wherein the certificate is presented from the second device via a storage server that stores the certificate in a format unreadable to the storage server. (Shockley Col. 28 ll. 62-66). In other words , the data that is stored on the storage server 420 is unreadable by the storage server, and unread able by anyone else other than the source device who originated the data , and by a device specifically authorized by the source device ( and notably not the controller device ).”)
Avetisov and Shockley are in the similar field of endeavor related to the technology of secure authentication.  It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Shockley into the invention of Avetisov for the purpose of being able to authenticate without revealing any secret identifying information. Based on the KSR v. TELEFLEX rationale, such an addition uses known methods (using a re-encryption key process) to produce a predictable result (to allow storage on a server where the server cannot itself decrypt the information) .   
Re. claim 32, Avetisov and Shockley teach the method as in claim 31, in addition Shockley teaches: wherein the storage server stores the certificate in a format unreadable to the first device until the second device provides a mechanism to convert the certificate into a format that is readable to the first device prior to presenting the certificate to the first device. ( Shockley Col 18, ll. 27-56, “In response to the request 550 ( or internal triggering ) , the storage server 420 may request the recipient - based rekeying key 418 … ( and may share the recipient device's public key 431 …too ) . Regardless , once the storage server has the recipient - based rekeying key 418 from the source device …, and also the source - encrypted source data 417 from the source device ( which , notably , may have been received contemporaneously with the rekeying key 418 , thus also possibly contemporaneously with the request or prior to obtaining the request ) , the storage server may , according to the techniques herein , re-encrypt the source – encrypted source data 417 with the recipient-based rekeying key 418 particular , the re-encrypting results in the source data 415 being encrypted with the recipient public key 431 of the particular recipient device 430 , i.e. , " recipient-based encrypted source data " 427 ( “ Rcpt - Bsd Encrypt Src Data ” shown below in Eq . 7…
Src - Encrypt Src Data ( 417 ) * Rcpt - Bsd Rekey Key
( 418 ) = ( Src Data ( 415 ) * Src Pub ( 411 ) ) * ( Src Pri ( 412 ) * Rcpt Pub ( 431 ) ) = Src Data ( 415 ) * ( Src Pub
( 411 ) * Src Pri ( 412 ) ) * Rcpt Pub ( 431 ) = Src Data
( 415 ) * ( 1 ) * Rcpt Pub ( 431 ) = Src Data ( 415 ) * Rcpt
Pub ( 431 ) = > Rcpt - Bsd Encrypt Src Data ( 427 )
Eq . 7 . Note that the storage server 420 is still unable to decrypt the source data encrypted with the recipient public key ( i.e. recipient - based encrypted source data 427 ) , since only the particular recipient device can do that with its private key.) Examiner submits that the Rcpt-Bsd Encrypt Src Data is encrypted by the recipient private key, and thus would be needed to decrypt on the first device. 
Avetisov and Shockley are in the similar field of endeavor related to the technology of secure authentication.  It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the features described by Shockley into the invention of Avetisov for the purpose of being able to authenticate without revealing any secret identifying information. Based on the KSR v. TELEFLEX rationale, such an addition uses known methods (using a re-encryption key process) to produce a predictable result (only the appropriate device to decrypt the information on the storage server).   
Re. claim 35, it is a computer readable medium claim that encompasses limitations similar to those of method claim 23. Therefore, claim 35 is rejected with the same motivation and rationale as applied against claim 23.

Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Wall et al. US 11,146,391 B2 discloses methods for proxy re-encryption keys for secure storage on cloud devices. 
GARNIER, US 20200287726 A1 discloses combining cryptographic keys for a multi-system remote control application.  

Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEVIN A AYALA whose telephone number is (571)270-3912. The examiner can normally be reached Monday-Thursday 8AM-5PM; Friday: Variable EST.
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, Jorge Ortiz-Criado can be reached at 571-272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.





/KEVIN AYALA/Primary Examiner, Art Unit 2496


Retrieved from "https://wikipatents.org/index.php?title=Patent_Application_17336644_-_SECURED_PRIVATE_CREDENTIAL_CERTIFICATE_-_Rejection&oldid=615937"
Cookies help us deliver our services. By using our services, you agree to our use of cookies.