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 .
Response to Arguments
In response to 35 USC 112 on pages 12-13, filed 08/19/2025, applicant argues that the amendments are resolved.
The 35 USC 112 is maintained please see the rejection below. Also, the claim does not indicate the that request message “requests issuance of a signed credential certificate for the user”.
In response to 35 USC 103 on pages 13-18, filed 08/19/2025, applicant argues that the prior art fails to teach receiving, at a user device responsive to a request message transmitted by a credential authority that requests issuance of a signed credential certificate for a user of the user device, the signed credential certificate issued by the credential authority and certifying one or more credentials associated with the user.
Avetisov teaches “receiving, at a user device, the signed credential certificate issued by the credential authority and certifying one or more credentials associated with the user”. Avetisov indicates [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”…). Avetisov shows receiving signed credential certificate and certifying the credential certificate.
Krahn teaches “receiving, at a user device responsive to a request message transmitted by a credential authority that requests issuance of a signed credential certificate for a user of the user device, the signed credential certificate issued by the credential authority”.Krahn indicates “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]”. Krahn shows user device receives the signed credential certificate from a request of a credential authority.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., that the credential authority itself transmit the issuance request and issue the certificate only after authenticating the user) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The claims as recited seems that the user device receives the issuance request and not the credential authority. Therefore, the claim does not indicate “that the certificate is issued by the credential authority responsive to a request message transmitted by the authority after authenticated the user.
In response to 35 USC 103 on pages 13-18, filed 08/19/2025, applicant argues that the prior art fails to teach wherein the storage server converts the singed credential certificate using only the conversion key provided by the user device and without possessing a user decryption key of the suer device or the private key of the questioning device.
The Examiner does not concede. Shockley teaches “wherein the storage server converts the singed credential certificate using only the conversion key provided by the user device and without possessing a user decryption key of the user device or the private key of the questioning device”. Shockley indicates 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. Col 13 II. 26-53, The storage server may also obtain a recipient-based rekeying key from the source device, the recipient-based rekeying key established through an encrypting combination of a source decryption key of the source device (e.g., a source private key) and a recipient public key of a particular recipient device.” As shown that the Shockley indicates convert the signed credential certificate using the conversion key. There is no weight of without possessing a user decryption key of the user device or the private key of the questioning device. Just by converting the signed credential certificate with the conversion key could mean that it does not possess a user decryption key of the user device or the private key of the questioning device.
Claim Objections
Claims 1, 13, 33 and 34 are objected to because of the following informalities: the claims recite “receiving, at a user device responsive to a request message transmitted by a credential authority that requests issuance of a signed credential certificate for a user of the user device, the signed credential certificate issued by the credential authority and certifying one or more credentials associated with the user”. The claim indicates “responsive to”, but there is no claim limitation that the credential authority is positively requesting. Appropriate correction is required.
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. claims 1, 13, 33 and 34; the claims recite “wherein the storage server converts the signed credential certificate using only the conversion key provided by the user device and without possessing a user decryption key of the user device or the private key of the question device”. It is unclear how the storage server can convert the signed credential certificate without a private key of the question device. The claim limitation previous indicated that the signed credential certificate is converted by the questioning device based on a private key of the questioning device.
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, the signed credential certificate issued by the credential authority and certifying one or more credentials associated with the user (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.”), wherein the storage server converts the singed credential certificate using only the conversion key provided by the user device and without possessing a user decryption key of the user device or the private key of the questioning device (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. Col 13 II. 26-53, The storage server may also obtain a recipient-based rekeying key from the source device, the recipient-based rekeying key established through an encrypting combination of a source decryption key of the source device (e.g., a source private key) and a recipient public key of a particular recipient device.”).
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, wherein the storage server converts the singed credential certificate using only the conversion key provided by the user device and without possessing a user decryption key of the user device or the private key of 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 responsive to a request message transmitted by a credential authority that requests issuance of a signed credential certificate for a user of the user device, the signed credential certificate issued by 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 by a storage server 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), wherein the storage server converts the singed credential certificate using only the conversion key provided by the user device and without possessing a user decryption key of the user device or the private key of the questioning device (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. Col 13 II. 26-53, The storage server may also obtain a recipient-based rekeying key from the source device, the recipient-based rekeying key established through an encrypting combination of a source decryption key of the source device (e.g., a source private key) and a recipient public key of a particular recipient 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 (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, wherein the storage server converts the singed credential certificate using only the conversion key provided by the user device and without possessing a user decryption key of the user device or the private key of 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 the questioning device a signed credential certificate issued by a credential authority for issuance of the signed credential certificate for the user (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 the questioning device a signed credential certificate issued by a credential authority for issuance of the signed credential certificate for the user 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 in response to a request message transmitted by the third entity after authenticating 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), wherein the certificate is stored at a storage server in a format that no device other than the second device can read (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).
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 ).), and wherein the second device provides a conversion key derived from a user decryption key of the second device and a public key of the first device to cause the storage server to convert the certificate into a format readable only by the first 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 .), wherein the storage server converts the certificate using only the conversion key and without possessing the user decryption key of the second device or a private key of the first device (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. Col 13 II. 26-53, The storage server may also obtain a recipient-based rekeying key from the source device, the recipient-based rekeying key established through an encrypting combination of a source decryption key of the source device (e.g., a source private key) and a recipient public key of a particular recipient 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 (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.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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