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 .
Detailed action
Claims 21-54 are pending and being considered.
Claims 21-24, 26, 28, 30-31, 33, 39-42, 45-46 and 53 have been amended.
Response to 103
Applicant’s arguments filed on 02/11/2026 have been fully considered are not persuasive. The applicant argues that the cited prior art fails to teach “a broadcast over a wireless communication interface of the mobile device, the broadcast configured to advertise an availability of an authentication service corresponding to the user authentication component” the examiner acknowledges applicant’s point of view but respectfully disagrees because Avetisov on [0034] teaches the remote server may then grant the client computing device or mobile computing device access to the online resources or restrict access to the online resources based on the result. Thus, in some embodiments, the remote server engages the authenticate service in response to an access attempt, receives a result subsequent to a user authenticating with the authentication service (e.g., with the mobile computing device), and authenticates a mobile device that engages the remote services based on the result. In some embodiments, the remote server may receive a result from the authentication service prior to a first access attempt. For example, a user may pre-authenticate on their mobile computing device with the authentication service. The result may be received by the remote server subsequent to the user authenticating with the authentication service (e.g., with the mobile computing device). Alternatively, in some embodiments where the user initiates the authentication process with the mobile computing device the mobile computing device may receive the result from the authentication service and present the result to the remote server. See also on [0170-0172] teaches the mobile device 101 may include an authentication application for providing authentication service.
Claim Objections
Claim 21, 31 and 45 objected to because of the following informalities:
Claims 21, 31 and 45 recites “…. present, to an operating system of the other device, an interface of an external authenticator device” the examiner suggests to clarify the purpose of presenting an interface of an external authenticator device to the operating system of the other device.
Claim 21 and 31 recites “….for presentation to an operating system of the other device” should read as “for presentation to [[an]] the operating system of the other device” to be consistence with “an operating system of the other device” as previously recited in the claim.
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.
Claim 21 and 31 recites “user authentication data based on the private credential…..” There is insufficient antecedent basis for the term “the private credential” in the claim.
Claim 21 and 31 recites “the trusted execution environment….” There is insufficient antecedent basis for this limitation in the claim.
Claim 21 recites “one or more challenge values generated using the private key stored within the mobile device” There is insufficient antecedent basis for this limitation in the claim.
Dependent claims are also rejected under the same rationales as set forth above.
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 21-43, 45, 46 and 49-54 are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov et al (hereinafter Avetisov) (US 20200067907) in view of ISHIMURA (US 20220308809).
Regarding claim 21 Avetisov teaches a tangible, non-transitory, machine-readable medium storing instructions that when executed by one or more processors of a computer system effectuate operations comprising: (Avetisov on [0014] teaches a tangible, non-transitory, machine-readable medium storing instructions that when executed by a data processing apparatus cause the data processing apparatus to perform operations);
establishing, for a user of a mobile device executing a user authentication component, a record comprising a public credential of a credential pair corresponding to an identity of the user, the user being permitted to access a secure asset under the identity of the user (Avetisov Fig 1 block 101, 120 and text on [0067] teaches user mobile device executing authentication application 120 (i.e., authentication component). See on [0012] teaches identity record established within the decentralized data store, the identity record comprising a public key i.e., identity record comprising public credentials. See on [0044] teaches user is permitted to access secure asset in response to authenticating the user under established identity);
initiating, by the mobile device, a broadcast over a wireless communication interface of the mobile device, the broadcast configured to advertise an availability of an authentication service corresponding to the user authentication component (Avetisov on [0034] teaches the remote server engages the authenticate service in response to an access attempt, receives a result subsequent to a user authenticating with the authentication service (e.g., with the mobile computing device), and authenticates a mobile device that engages the remote services based on the result. In some embodiments, the remote server may receive a result from the authentication service prior to a first access attempt. For example, a user may pre-authenticate on their mobile computing device with the authentication service. The result may be received by the remote server subsequent to the user authenticating with the authentication service (e.g., with the mobile computing device). See also on [0170-0172] teaches the mobile device 101 may include an authentication application for providing authentication service);
establishing a direct wireless communication session between the other device and the mobile device (Avetisov on [0053] teaches the computing environment 100 may include a mobile device 101, a client device 135, a relaying party 145, 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. In addition, embodiments of the example computing environment 100 may include a mobile computing client device, such as mobile device 101, that supports client-side out-of-band authentication based on a secure channel to a trusted execution environment);
configuring, by the other device, a virtual device on a USB of the other device, the virtual device being configured to present, to an operating system of the other device, an interface of an external authenticator device (Avetisov on [0056] teaches the mobile device 101 may be any client device, the mobile device may optionally include a trusted execution environment which, in some cases, may be an external, portable device capable of being coupled via a bus, like USB, to any client device including a suitable interface. See on [0092 and 0159] teaches client device 135 may be a terminal device or otherwise configured to provide a user interface for terminal access to one or more computing devices or virtual machines that may include or provide access to a secure asset or be a secure asset themselves);
receiving, from the other device through the direct wireless communication session: a request to access the secure asset under the identity of the user for presentation to an operating system of the other device via the virtual device, and a selection to authenticate a user of the other device under the identity of the user of the mobile device via the mobile device, the selection corresponding to an authentication transaction initiated via the virtual device (Avetisov on [0092-0095] teaches an example client device 135 may be a terminal device or otherwise configured to provide a user interface for terminal access to one or more computing devices or virtual machines (i.e., virtual device) that may include or provide access to a secure asset or be a secure asset themselves (i.e., authentication transaction). Further teaches the application 110 may be a web browser configured to request data on and receive data from the server 145 for presentation on a display of the client device 135 (i.e., presentation to an operating system). Accordingly, the application 110 may be configured to retrieve data from the server 145 and present the data received from the server to the user. In some cases, the server 145 may redirect the application 110 to retrieve some or all data from one or more other servers, like server 155. The retrieved data, when executed or processed, may cause the application 110 to present on the display of the client device 135 a log-in page or other user interface including one or more fields or other user interface elements configured to receive user credential 111 input for accessing the online resource 14. See Fig 3B block 341 and text on [0238-0240] teaches authentication of a device with another device in an out-of-band authentication process, the process 300B begins with an access attempt by a client device (i.e., another device) at the relying party 145. The access attempt may be to a secure asset of the relying party 145, such as an online resource accessible by client devices over a network. The relying party 145 may pass information about the access attempt to the authentication server 155. The information passed to the authentication server 155 may include information such as user account information or device information associated with the access attempt. For example, the relying party 145 may receive a user account identifier at block 341 and pass the user account identifier to the authentication server 155. The authentication server 155, based on the user account identifier, may identify a UID Record 342. The UID record identified by the authentication server 155 may include records or a listing of one or more devices registered with the authentication server 155 for user authentication i.e., receiving user account identifier as selection to authenticate user based on user account identifier associated with UID record for authentication);
authenticating, by the mobile device, the user of the other device based on the authentication response to one or more challenge values generated using the private key stored within the mobile (Avetisov on [0065] teaches the mobile device 101 may be a mobile computing client device to which a user has access to and may use to authenticate a request to access a secure asset like online resources. Notably, as is often the case, the request to access online resources may not originate from the mobile device 101. Rather, the mobile device 101 serves a client-side role in an out-of-band authentication process for that request to access online resources. By way of example, the request to access online resources may originate from a different client device, such as client device 135. See on [0083] teaches the mobile device 101 may interface, via the API 104, with the TEE 103 to securely authenticate a user based on the user providing input that matches a valid representation of a corresponding credential 109. See on [0112] teaches the authentication result indicates whether the user of the client device 135 successfully authenticated with the authentication server 155 (e.g., via the mobile device 101). See on [0267] teaches a client device 135, attempting to access a secure asset as described herein. Thus, the notification may be received in association with an out-of-band authentication process in which the user uses the mobile device 101 to authenticate the access attempt by the client device 135 . See on [033] teaches private key may be used to sign data and a corresponding public key used to verify the data was signed by the holder of the private key. Further, for example, the data may be a representation of credential values, like a cryptographic hash of credential values, which may be signed within a trusted execution environment of a mobile device (e.g., by a private key retained securely within the environment, which may be a key of a component), and may be verified in a similar fashion. i.e., private credential authenticating user is interpreted in view of [0033, 0116, 0134 and 0137] of spec which discloses authenticating user based on credential supplied by the user such as PIN or biometric);
generating, by the mobile device, user authentication data based on the private credential stored within the trusted execution environment of the mobile device, wherein the private credential is restricted to cryptographic operations performed within the trusted execution environment of the mobile device (Avetisov on [0043, 0050, 0053 and 0096] teaches a private key may be used to sign data and a corresponding public key used to verify the data was signed by the holder of the private key. Further, for example, the data may be a representation of credential values, like a cryptographic hash of credential values, which may be signed within a trusted execution environment of a mobile device (e.g., by a private key retained securely within the environment, which may be a key of a component), and may be verified in a similar fashion. See on [0159] teaches 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 i.e., private key is used to sign data equivalent to cryptographic operation);
receiving by the other device, the user authentication data through the direct wireless communication session (Avetisov on [0238-0243] teaches the authentication server 155 may receive a response to the notification from the mobile device that includes data corresponding to representations of requested credentials input by the user or results of any verifications performed within the TEE. The response may also include signed data (i.e., authentication data based on private key [0263]) for verification of the data. Further teaches authentication of a device with another device in an out-of-band authentication process, the process 300B begins with an access attempt by a client device (i.e., another device) at the relying party 145. The access attempt may be to a secure asset of the relying party 145, such as an online resource accessible by client devices over a network. The relying party 145 may pass information about the access attempt to the authentication server 155. The information passed to the authentication server 155 may include information such as user account information or device information associated with the access attempt. For example, the relying party 145 may receive a user account identifier at block 341 and pass the user account identifier to the authentication server 155. The authentication server 155, based on the user account identifier, may identify a UID Record 342. The UID record identified by the authentication server 155 may include records or a listing of one or more devices registered with the authentication server 155 for user authentication i.e., receiving user account identifier as selection to authenticate user based on user account identifier associated with UID record for authentication. Further teaches mobile device 101 having a trusted execution environment and previously registered with the authentication server 155, may receive the notification from the authentication server. Further teaches the notification may be determined responsive to information stored in the device record. For example, the device record may include a device identifier applicable to transmit the notification to the selected device. Similarly, the device record may store information about the different credentials which a user of the device may provide to authenticate with the authorization server using that device, the mobile device 101 may process 345 the notification within the trusted execution environment. The result of the processing 345 by the mobile device 101 may include various data transmitted to the authentication server 155 for authentication of the user of the mobile device);
verifying the by the other device user authentication data generated by the mobile device based on the record to determine whether the user of the other device is authenticated to the identity of the user access the secure asset from the other device (Avetisov on [0243-0245] teaches the authentication server 155 may use a public key for signature verification previously received from the mobile device 101 in a registration process to verify the data was generated by the mobile device, the authentication server 155 may also verify whether the data (e.g., determined to have originated from the mobile device based on the signature) matches stored data. For example, the authentication server 155 may determine whether a received representation of the credential matches a previously stored representation of the credential. Further, the authentication server 155 may determine whether the received data corresponds to a notification 344 requesting that data. For example, the received data or verification process (e.g., using signed data) may include a timestamp or other identifying information for a notification (e.g., the notification from step 344) such that authentication server 155 can determine that the response was generated for a specific notification that requested it);
and permitting, based on the verifying, the other device to access the secure asset under the identity of the user of the other device (Avetisov on [0243-0245] teaches the authentication server 155 transmits an authentication result to the relying party, for example the authentication result may indicate that the user was authenticated and the access attempt by the client should be granted, the result includes identifying information for the client device attempting to access the relying party based on the information previously received from the relying party 145 in association with the access attempt such that the attempt is granted or denied only for that particular device).
Avetisov fails to explicitly teach establishing wireless communication over a local wireless transport protocol, however ISHIMURA from analogous art teaches
detecting, by another device, the broadcast (ISHIMURA on [0076-0077] teaches a communication may be detected from the second terminal apparatus 250 within a specific period of time from the establishment of the connection and the second terminal apparatus 250 may be nearer to the information processing apparatus 100 than the terminal apparatus 250. A determination as to whether the terminal apparatus 250 is nearer to the information processing apparatus 100 may be performed based on the strength of a radio wave received from the terminal apparatus);
establishing a direct wireless communication session between the other device and the mobile device over a local wireless transport protocol (ISHIMURA on [0046 and 0086] teaches wireless communication module 195A (an example of a communication unit) performs a wireless communication with the terminal apparatus 250. The wireless communication may be Bluetooth, Bluetooth Low Energy (BLE), or Wi-Fi)
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of ISHIMURA into the teaching of Avetisov by detecting communication from mobile device over local wireless transport protocol. One would be motivated to do so in order to establish secure communication between wireless devices over short-range communication based on detecting identification information in the communication detected by nearby device (ISHIMURA [0003-0007]).
Regarding claim 31 Avetisov teaches a tangible, non-transitory, machine-readable medium storing instructions that when executed by one or more processors of a computer system effectuate operations comprising: (Avetisov on [0014] teaches a tangible, non-transitory, machine-readable medium storing instructions that when executed by a data processing apparatus cause the data processing apparatus to perform operations);
establishing, for a mobile device executing a user authentication component, a record of an identity of a user of a mobile device, the record indicative of the mobile device and credentials by which the user authenticates on the mobile device; (Avetisov Fig 1 block 101, 120 and text on [0067] teaches user mobile device executing authentication application 120 (i.e., authentication component). See on [0012] teaches identity record established within the decentralized data store, the identity record comprising a public key for authenticating i.e., identity record comprising credentials. See on [0044] teaches user is permitted to access secure asset in response to authenticating the user under established identity);
initiating, by the mobile device, a broadcast over a wireless communication interface of the mobile device, the broadcast configured to advertise an availability of an authentication service corresponding to the user authentication component (Avetisov on [0034] teaches the remote server engages the authenticate service in response to an access attempt, receives a result subsequent to a user authenticating with the authentication service (e.g., with the mobile computing device), and authenticates a mobile device that engages the remote services based on the result. In some embodiments, the remote server may receive a result from the authentication service prior to a first access attempt. For example, a user may pre-authenticate on their mobile computing device with the authentication service. The result may be received by the remote server subsequent to the user authenticating with the authentication service (e.g., with the mobile computing device). See also on [0170-0172] teaches the mobile device 101 may include an authentication application for providing authentication service);
establishing a direct wireless communication session between the second device and the mobile device (Avetisov on [0053] teaches the computing environment 100 may include a mobile device 101, a client device 135, a relaying party 145, 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. In addition, embodiments of the example computing environment 100 may include a mobile computing client device, such as mobile device 101, that supports client-side out-of-band authentication based on a secure channel to a trusted execution environment);
configuring, by the second device, a virtual device on a USB of the other device, the virtual device being configured to present, to an operating system of the other device, an interface of an external authenticator device (Avetisov on [0056] teaches the mobile device 101 may be any client device, the mobile device may optionally include a trusted execution environment which, in some cases, may be an external, portable device capable of being coupled via a bus, like USB, to any client device including a suitable interface. See on [0092 and 0159] teaches client device 135 may be a terminal device or otherwise configured to provide a user interface for terminal access to one or more computing devices or virtual machines that may include or provide access to a secure asset or be a secure asset themselves);
receiving, from the second device, a request to access a secure asset under an identity of a user of the second device for presentation to an operating system of the computing device via the virtual device and a selection to authenticate via the mobile device executing the user authentication component, the selection corresponding to an authentication transaction initiated via the virtual device (Avetisov on [0092-0095] teaches an example client device 135 may be a terminal device or otherwise configured to provide a user interface for terminal access to one or more computing devices or virtual machines (i.e., virtual device) that may include or provide access to a secure asset or be a secure asset themselves (i.e., authentication transaction). Further teaches the application 110 may be a web browser configured to request data on and receive data from the server 145 for presentation on a display of the client device 135 (i.e., presentation to an operating system). Accordingly, the application 110 may be configured to retrieve data from the server 145 and present the data received from the server to the user. In some cases, the server 145 may redirect the application 110 to retrieve some or all data from one or more other servers, like server 155. The retrieved data, when executed or processed, may cause the application 110 to present on the display of the client device 135 a log-in page or other user interface including one or more fields or other user interface elements configured to receive user credential 111 input for accessing the online resource 14. See Fig 3B block 341 and text on [0238-0240] teaches authentication of a device with another device in an out-of-band authentication process, the process 300B begins with an access attempt by a client device (i.e., another device) at the relying party 145. The access attempt may be to a secure asset of the relying party 145, such as an online resource accessible by client devices over a network. The relying party 145 may pass information about the access attempt to the authentication server 155. The information passed to the authentication server 155 may include information such as user account information or device information associated with the access attempt. For example, the relying party 145 may receive a user account identifier at block 341 and pass the user account identifier to the authentication server 155. The authentication server 155, based on the user account identifier, may identify a UID Record 342. The UID record identified by the authentication server 155 may include records or a listing of one or more devices registered with the authentication server 155 for user authentication i.e., receiving user account identifier as selection to authenticate user based on user account identifier associated with UID record for authentication);
causing the mobile device to authenticate the user of the mobile device (Avetisov on [0065] teaches the mobile device 101 may be a mobile computing client device to which a user has access to and may use to authenticate a request to access a secure asset like online resources. Notably, as is often the case, the request to access online resources may not originate from the mobile device 101. Rather, the mobile device 101 serves a client-side role in an out-of-band authentication process for that request to access online resources. By way of example, the request to access online resources may originate from a different client device, such as client device 135. See on [0083] the mobile device 101 may interface, via the API 104, with the TEE 103 to securely authenticate a user based on the user providing input that matches a valid representation of a corresponding credential 109. See on [0112] teaches the authentication result indicates whether the user of the client device 135 successfully authenticated with the authentication server 155 (e.g., via the mobile device 101). See on [0267] teaches a client device 135, attempting to access a secure asset as described herein. Thus, the notification may be received in association with an out-of-band authentication process in which the user uses the mobile device 101 to authenticate the access attempt by the client device 135);
causing the second device to request the mobile device to generate user authentication data on an authentication protocol based on the private credential stored within the trusted execution environment of the mobile device, wherein the private credential is restricted to cryptographic operations performed within the trusted execution environment of the mobile device (Avetisov on [0210 and 0241] teaches a notification (i.e., request which causes generation of authentication data by the mobile device as shown in Fig 3B block 345 and 346) is received in response to a client device (i.e., second device) different from the mobile device 1101, like a client device 135, attempting to access a secure asset as described herein. Thus, the notification may be received in association with an out-of-band authentication process in which the user uses the mobile device 101 to authenticate the access attempt by the client device 135. See on [0043, 0050, 0053 and 0096] teaches a private key may be used to sign data and a corresponding public key used to verify the data was signed by the holder of the private key. Further, for example, the data may be a representation of credential values, like a cryptographic hash of credential values, which may be signed within a trusted execution environment of a mobile device (e.g., by a private key retained securely within the environment, which may be a key of a component), and may be verified in a similar fashion. See on [0159] teaches 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 i.e., private key is used to sign data equivalent to cryptographic operation);
receiving by the second device the user authentication data generated by the mobile device in the authentication protocol through the direct wireless communication session (Avetisov on [0238-0243] teaches the authentication server 155 may receive a response to the notification from the mobile device that includes data corresponding to representations of requested credentials input by the user or results of any verifications performed within the TEE. The response may also include signed data (i.e., authentication data based on private key [0263]) for verification of the data. Further teaches authentication of a device with another device in an out-of-band authentication process, the process 300B begins with an access attempt by a client device (i.e., another device) at the relying party 145. The access attempt may be to a secure asset of the relying party 145, such as an online resource accessible by client devices over a network. The relying party 145 may pass information about the access attempt to the authentication server 155. The information passed to the authentication server 155 may include information such as user account information or device information associated with the access attempt. For example, the relying party 145 may receive a user account identifier at block 341 and pass the user account identifier to the authentication server 155. The authentication server 155, based on the user account identifier, may identify a UID Record 342. The UID record identified by the authentication server 155 may include records or a listing of one or more devices registered with the authentication server 155 for user authentication i.e., receiving user account identifier as selection to authenticate user based on user account identifier associated with UID record for authentication. Further teaches mobile device 101 having a trusted execution environment and previously registered with the authentication server 155, may receive the notification from the authentication server. Further teaches the notification may be determined responsive to information stored in the device record. For example, the device record may include a device identifier applicable to transmit the notification to the selected device. Similarly, the device record may store information about the different credentials which a user of the device may provide to authenticate with the authorization server using that device, the mobile device 101 may process 345 the notification within the trusted execution environment. The result of the processing 345 by the mobile device 101 may include various data transmitted to the authentication server 155 for authentication of the user of the mobile device);
verifying by the second device the authentication data based on the record to determine whether the user of the mobile device is authenticated to access the secure asset from the second device (Avetisov on [0243-0245] teaches the authentication server 155 may use a public key for signature verification previously received from the mobile device 101 in a registration process to verify the data was generated by the mobile device, the authentication server 155 may also verify whether the data (e.g., determined to have originated from the mobile device based on the signature) matches stored data. For example, the authentication server 155 may determine whether a received representation of the credential matches a previously stored representation of the credential. Further, the authentication server 155 may determine whether the received data corresponds to a notification 344 requesting that data. For example, the received data or verification process (e.g., using signed data) may include a timestamp or other identifying information for a notification (e.g., the notification from step 344) such that authentication server 155 can determine that the response was generated for a specific notification that requested it);
and permitting, based on the verifying, the second device to access the secure asset under the identity of the user of the second device (Avetisov on [0243-0245] teaches the authentication server 155 transmits an authentication result to the relying party, for example the authentication result may indicate that the user was authenticated and the access attempt by the client should be granted, , the result includes identifying information for the client device attempting to access the relying party based on the information previously received from the relying party 145 in association with the access attempt such that the attempt is granted or denied only for that particular device).
Avetisov fails to explicitly teach establishing wireless communication over a local wireless transport protocol, however ISHIMURA from analogous art teaches
detecting, by a second device, the broadcast (ISHIMURA on [0076-0077] teaches a communication may be detected from the second terminal apparatus 250 within a specific period of time from the establishment of the connection and the second terminal apparatus 250 may be nearer to the information processing apparatus 100 than the terminal apparatus 250. A determination as to whether the terminal apparatus 250 is nearer to the information processing apparatus 100 may be performed based on the strength of a radio wave received from the terminal apparatus);
establishing a direct wireless communication session between the other device and the mobile device over a local wireless transport protocol (ISHIMURA on [0046 and 0086] teaches wireless communication module 195A (an example of a communication unit) performs a wireless communication with the terminal apparatus 250. The wireless communication may be Bluetooth, Bluetooth Low Energy (BLE), or Wi-Fi).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of ISHIMURA into the teaching of Avetisov by detecting communication from mobile device over local wireless transport protocol. One would be motivated to do so in order to establish secure communication between wireless devices over short-range communication based on detecting identification information in the communication detected by nearby device (ISHIMURA [0003-0007]).
Regarding claim 22 and 32 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 21 and 31 above, Avetisov further teaches wherein establishing the record corresponding to the identity of the user comprises: obtaining the public credential corresponding to the mobile device and data signed using the private credential by the mobile device, the signed data being verifiable based on the public credential (Avetisov on [0243] teaches the response may also include signed data for verification of the data. For example, the authentication server 155 may use a public key for signature verification previously received from the mobile device 101 in a registration process to verify the data was generated by the mobile device having the corresponding private key);
and wherein: the private credential is accessible to the mobile device for generating the user authentication data responsive to authentication of the user upon a user credential by the user authentication component (Avetisov on [0243] teaches the response may also include signed data for verification of the data. For example, the authentication server 155 may use a public key for signature verification previously received from the mobile device 101 in a registration process to verify the data was generated by the mobile device having the corresponding private key. See on [0086] teaches the authentication application 120 may receive credentials 116 (e.g., public keys and representations of credentials). The verification process indicating that (1) and (2) were provided by the TEE 103 as only the TEE stores the private key operable to generate signed data verifiable by the data, organized into the string, and the corresponding public key).
Regarding claim 23 and 33 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 22 and 32 above, Avetisov further teaches wherein: the mobile device generates the credential pair, wherein the public credential is a public key and the private credential is a private key, the mobile device authenticates the user prior to permitting use of the private key, and the mobile device generates the signed data based on the private key (Avetisov on [0243] teaches the response may also include signed data for verification of the data. For example, the authentication server 155 may use a public key for signature verification previously received from the mobile device 101 in a registration process to verify the data was generated by the mobile device having the corresponding private key. See on [0086] teaches the authentication application 120 may receive credentials 116 (e.g., public keys and representations of credentials). The verification process indicating that (1) and (2) were provided by the TEE 103 as only the TEE stores the private key operable to generate signed data verifiable by the data, organized into the string, and the corresponding public key).
Regarding claim 24 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 23 above, Avetisov further teaches wherein: the user authentication component of the mobile device authenticates the user on one or more user credentials (Avetisov on [0243] teaches the response may also include signed data for verification of the data. For example, the authentication server 155 may use a public key for signature verification previously received from the mobile device 101 in a registration process to verify the data was generated by the mobile device having the corresponding private key. See on [0086] teaches the authentication application 120 may receive credentials 116 (e.g., public keys and representations of credentials). The verification process indicating that (1) and (2) were provided by the TEE 103 as only the TEE stores the private key operable to generate signed data verifiable by the data, organized into the string, and the corresponding public key);
and the mobile device generates the signed data based on the private key and the one or more of the user credential (Avetisov on [0044] teaches a server receives cryptographically signed data, verify that the cryptographically signed data was signed by an entity (e.g., a specific mobile computing device of a user) with to a private cryptographic key corresponding to a public cryptographic key associated with the user's account or established identity of the user, and then, determine whether the signed data indicates that the user-supplied credential values match those previously supplied during registration).
Regarding claim 25 and 36 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 21 and 31 above, Avetisov further teaches further comprising transmitting, to the other device, in response to the selection to authenticate the user of the other device under the identity of the user via the mobile device: identifying information corresponding to a server device for presentation to the mobile device (Avetisov Fig 3B block 341 and text on [0238-0240] teaches the relying party 145 may receive a user account identifier at block 341 and pass the user account identifier to the authentication server 155. The authentication server 155, based on the user account identifier, may identify a UID Record 342. The UID record identified by the authentication server 155 may include records or a listing of one or more devices registered with the authentication server 155 for user authentication).
Regarding claim 26 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 21 above, Avetisov further teaches wherein receiving, from another device, a request to access a secure asset under the identity of the user comprises: receiving the request from an application executed by the other device, receiving the request via a website accessed by the another device, receiving the request via a web application accessed by the other device, or receiving the request from an operating system executed by the other device (Avetisov on [0094-0095] teaches the client device 135 may attempt to access the online resource 147 on or via one or more servers 145 using an application 110 installed to the client device 135. In another example, a client device 135 may attempt to access a secured asset such as an application 110 executed on the client device).
Regarding claim 27 and 34 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 21 and 31 above, Avetisov further teaches wherein receiving, from another device, a selection to authenticate the user of the other device under the identity of the user via the mobile device comprises: receiving an indication of the selection being performed within a user interface of an application executed by the other device, receiving an indication of the selection being performed within a user interface of a website accessed by the another device, receiving an indication of the selection being performed within a user interface of a web application accessed by the other device, or receiving an indication of the selection being performed within a user-level account login interface of an operating system executed by the another device (Avetisov on [0094-0096] teaches the client device 135 may attempt to access the online resource 147 on or via one or more servers 145 using an application 110 installed to the client device 135. In another example, a client device 135 may attempt to access a secured asset such as an application 110 executed on the client device, the client device 135 may include an application 110 configured to access the online resource 147. For example, the application 110 may be a web browser configured to request data on and receive data from the server 145 for presentation on a display of the client device 135. Accordingly, the application 110 may be configured to retrieve data from the server 145 and present the data received from the server to the user).
Regarding claim 28 and 35 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 21 and 31 respectively, Avetisov further teaches wherein receiving user authentication data generated based on a private credential of the credential pair by the mobile device comprises:wherein: the user authentication component of the mobile device authenticates the user on one or more user credentials (Avetisov on [0088-0090] teaches the authentication application 120 may be configured to verify that the shared key was generated within the TEE 103, such as by verifying a signature of the TEE. In another example, the authentication application 120 may request a public key of a key pair from the TEE 103. The authentication application 120 may be configured to verify that the public key was generated within the TEE 103, such as by verifying a signature provided by the TEE);
the mobile device generates the user authentication data after the authentication of the user, and the user authentication data comprises a cryptographic signature of data using the private credential (Avetisov on [0240-0243] teaches after verifying user record UID associated with user account identifier. The serve sends request for generating authentication data comprising data signed with private key).
receiving the user authentication data in a FIDO2 compliant protocol (ISHIMURA on [0077 and 0129] teaches authentication data in FIDO2 protocol).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of ISHIMURA into the teaching of Avetisov by receiving the user authentication data in a FIDO2 compliant protocol. One would be motivated to do so in order to establish secure communication between wireless devices over short-range communication based on detecting identification information in the communication detected by nearby device (ISHIMURA [0003-0007]).
Regarding claim 29 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 21 above, Avetisov further teaches verifying the user authentication data generated by the mobile device based on the record to determine whether the user of the other device is authenticated to the identity of the user access the secure asset from the another device comprises: accessing the record based on an identifier associated with the access attempt by the other device; obtaining the public credential associated with the record; and verifying the authentication data using the public credential (Avetisov on [0240-0243] teaches the authentication server 155, based on the user account identifier, may identify a UID Record 342, such as within a repository storing various UID Records corresponding to different users or accounts. The UID record may be associated with or otherwise include the user account identifier for identification by the authentication server 155 based on information about an access attempt by a client device. The UID record identified by the authentication server 155 may include records or a listing of one or more devices registered with the authentication server 155 for user authentication. The authentication server 155 may receive a response to the notification from the mobile device that includes data corresponding to representations of requested credentials input by the user or results of any verifications performed within the TEE. The response may also include signed data for verification of the data. For example, the authentication server 155 may use a public key for signature verification previously received from the mobile device 101 in a registration process to verify the data was generated by the mobile device having the corresponding private key).
Regarding claim 30 and 40 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 21 and 31 above, Avetisov further teaches wherein permitting, based on the verifying, the other device to access the secure asset under the identity of the user comprises: granting access to an application executed by the another device, granting access to a website accessed by the other device under an account of the user, granting access to a web application accessed by the another device under an account of the user, or granting access to a user-level account of an operating system executed by the other device, the user-level account corresponding to the user (Avetisov on [0243-0245] teaches the authentication server 155 transmits an authentication result to the relying party, for example the authentication result may indicate that the user was authenticated and the access attempt by the client should be granted, , the result includes identifying information for the client device attempting to access the relying party based on the information previously received from the relying party 145 in association with the access attempt such that the attempt is granted or denied only for that particular device. See on [0033-0034] teaches the client computing device is granted access to the online resources provided by the website or the native application).
Regarding claim 37 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 36 above, ISHIMURA teaches the authentication protocol is a FIDO2 or Smart Card authenticator compliant protocol (ISHIMURA on [0077 and 0129] teaches authentication data in FIDO2 protocol);
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of ISHIMURA into the teaching of Avetisov by receiving the user authentication data in a FIDO2 compliant protocol. One would be motivated to do so in order to establish secure communication between wireless devices over short-range communication based on detecting identification information in the communication detected by nearby device (ISHIMURA [0003-0007]).
Regarding claim 38 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 31 above, Avetisov further teaches wherein receiving the user authentication data generated by the mobile device in the authentication protocol further comprises: receiving, over a network connection from the second device, the user authentication data in the authentication protocol, the user authentication data being translated to the authentication protocol by the second device from a direct wireless connection to the mobile device, (Avetisov on [0238--0244] teaches the mobile device 101 may process 345 the notification within the trusted execution environment. The result of the processing 345 by the mobile device 101 may include various data transmitted to the authentication server 155 for authentication of the user of the mobile device. the authentication server 155 may receive a response to the notification from the mobile device that includes data corresponding to representations of requested credentials input by the user or results of any verifications performed within the TEE. The response may also include signed data for verification of the data. For example, the authentication server 155 may use a public key for signature verification previously received from the mobile device 101 in a registration process to verify the data was generated by the mobile device having the corresponding private key. In turn, the authentication server 155 may also verify whether the data (e.g., determined to have originated from the mobile device based on the signature) matches stored data).
ISHIMURA teaches wherein: the user authentication data is received over a FIDO2 or Smart Card authenticator compliant protocol (ISHIMURA on [0077 and 0129] teaches authentication data in FIDO2 protocol);
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of ISHIMURA into the teaching of Avetisov by receiving the user authentication data in a FIDO2 compliant protocol. One would be motivated to do so in order to establish secure communication between wireless devices over short-range communication based on detecting identification information in the communication detected by nearby device (ISHIMURA [0003-0007]).
Regarding claim 39 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 31 above, Avetisov further teaches wherein verifying the authentication data based on the record to determine whether the user is authenticated to access the secure asset from the second device comprises: accessing the record based on an identifier received in association with the access attempt by the second device; obtaining a cryptographic key associated with the record; and verifying the authentication data using the cryptographic key (Avetisov on [0240-0243] teaches the authentication server 155, based on the user account identifier, may identify a UID Record 342, such as within a repository storing various UID Records corresponding to different users or accounts. The UID record may be associated with or otherwise include the user account identifier for identification by the authentication server 155 based on information about an access attempt by a client device. The UID record identified by the authentication server 155 may include records or a listing of one or more devices registered with the authentication server 155 for user authentication. The authentication server 155 may receive a response to the notification from the mobile device that includes data corresponding to representations of requested credentials input by the user or results of any verifications performed within the TEE. The response may also include signed data for verification of the data. For example, the authentication server 155 may use a public key for signature verification previously received from the mobile device 101 in a registration process to verify the data was generated by the mobile device having the corresponding private key).
Regarding claim 41 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 21 above, Avetisov further teaches and transmitting, by the mobile device, a cryptographically signed authentication response over the direct wireless communication session, wherein the authentication response comprises user authentication data generated using a private credential stored within the trusted execution environment of the mobile device (Avetisov on [0243] teaches the authentication server 155 may receive a response to the notification from the mobile device that includes data corresponding to representations of requested credentials input by the user or results of any verifications performed within the TEE. The response may also include signed data (i.e., authentication data based on private key [0263]) for verification of the data).
ISHIMURA teaches wherein receiving, from another device, a selection to authenticate the user of the other device under the identity of the user via the mobile device comprises: establishing a direct wireless communication session between the mobile device and the other device using at least one of: Bluetooth, WiFi Direct, Near-Field Communication (NFC), or optical signals (ISHIMURA on [0046 and 0086] teaches wireless communication module 195A (an example of a communication unit) performs a wireless communication with the terminal apparatus 250. The wireless communication may be Bluetooth, Bluetooth Low Energy (BLE), or Wi-Fi);
detecting, by the mobile device, a request for authentication from the other device via a wireless beacon signal transmitted on the direct wireless communication session (ISHIMURA on [0046 and 0086] teaches wireless communication module 195A (an example of a communication unit) performs a wireless communication with the terminal apparatus 250. The wireless communication may be Bluetooth, Bluetooth Low Energy (BLE), or Wi-Fi).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of ISHIMURA into the teaching of Avetisov by detecting communication from mobile device over local wireless transport protocol. One would be motivated to do so in order to establish secure communication between wireless devices over short-range communication based on detecting identification information in the communication detected by nearby device (ISHIMURA [0003-0007]).
Regarding claim 42 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 21 above, Avetisov further teaches wherein the record comprising the public credential of the credential pair corresponding to the identity of the user is stored in a remotely accessible authentication repository (Avetisov on [0137-0138 and 0164-0165] teaches a transaction for data storage may include representations of credentials, public keys, user account identifiers, or other information stored outside of the directed acyclic graph 205 of cryptographic hash pointers. In some embodiments, a public key may be considered a representation of a credential (e.g., a private key) because it is representative of some other knowledge (the private key) held in confidence by a user or entity without being exposed. Rather, signed data is exposed for signature verification as proof that the user or entity has access to the private key. In some embodiments, a public key may be a user account identifier or an identifier of an entity, as that public key corresponds to a private key retained by a given user or entity);
wherein: the public credential is stored in an authentication server or an authorization repository associated with the user identity (Avetisov on [0137-0138 and 0164-0165] teaches a transaction for data storage may include representations of credentials, public keys, user account identifiers, or other information stored outside of the directed acyclic graph 205 of cryptographic hash pointers. In some embodiments, a public key may be considered a representation of a credential (e.g., a private key) because it is representative of some other knowledge (the private key) held in confidence by a user or entity without being exposed. Rather, signed data is exposed for signature verification as proof that the user or entity has access to the private key. In some embodiments, a public key may be a user account identifier or an identifier of an entity, as that public key corresponds to a private key retained by a given user or entity);
and access to the private credential for cryptographic operations is restricted to the trusted execution environment and subject to user authentication using one or more authentication factors, including at least one of a biometric identifier, a personal identification number, or a cryptographic challenge-response mechanism (Avetisov on [0139, 0182 and 0211] authenticating user using PIN or biometric. In response to obtaining a notification for processing, an authentication application 220 may interface with a TEE of the mobile device 101 to prompt the user to authenticate with the mobile device 101, such as by biometric authentication or entering credential values like a passcode, pin, or other values. In some embodiments, a notification may request authentication by one or more specific credential values or biometrics, which the user may supply for processing within the TEE. As described previously, credential values may reside with the user or within the TEE. For example, when the user authenticates on the mobile device 101 via a biometric value, the TEE may analyze the biometric values supplied by the user to determine whether the supplied biometric values are indicative of the user who established representations of those values within the TEE).
Regarding claim 43 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 21 above, Avetisov further teaches wherein the user authentication component is further configured to: monitor wireless communication channels for authentication-related signals from other devices, the signals indicating a request to authenticate a user to access a secure asset (Avetisov on [0206 and 0235] request to authenticate user to access asset);
identify an authentication request based on an association with an identifier linked to the user, wherein the identifier corresponds to a credential pair registered for authentication(Avetisov on [0137-0138 and 0164-0165] teaches a transaction for data storage may include representations of credentials, public keys, user account identifiers, or other information stored outside of the directed acyclic graph 205 of cryptographic hash pointers. In some embodiments, a public key may be considered a representation of a credential (e.g., a private key) because it is representative of some other knowledge (the private key) held in confidence by a user or entity without being exposed. Rather, signed data is exposed for signature verification as proof that the user or entity has access to the private key. In some embodiments, a public key may be a user account identifier or an identifier of an entity, as that public key corresponds to a private key retained by a given user or entity);
present an authentication request notification on a user interface of the mobile device, the notification including details of the requesting device and the requested secure asset (Avetisov on [0210-0212] teaches the notification may be received in association with an out-of-band authentication process in which the user uses the mobile device 101 to authenticate the access attempt by the client device);
receive user input approving the authentication request via an interactive prompt (Avetisov on [0313] teaches the authentication application may obtain the signed data 516 indicative of the user approving the request to federate a user account and indicative of user ownership of the Net ID (e.g., a zero knowledge proof));
generate authentication data using a private credential stored within an isolated execution environment of the mobile device (Avetisov on [0176, 0217 and 0243] teaches the authentication server 155 may transmit a notification of the request received from the additional device to the mobile device 101. The authentication server 155 may also transmit a similar notification in response to a request received from a different user to be added as an authorized user of the Net ID 271 (e.g., with their own device). In response to the notification, the authentication application 220 on the mobile device 101 of the user having previously established the Net ID 271 may be configured to prompt the user of the mobile device 101 to authorize the request, such as by signature of data (e.g., notification, request, Net ID, or other data indicating approval) within the TEE of the mobile device with the private key corresponding to the public key associated with the Net ID 271);
transmit the generated authentication data to the requesting device for verification (Avetisov on [0176, 0217 and 0243] teaches the authentication server 155 may transmit a notification of the request received from the additional device to the mobile device 101. The authentication server 155 may also transmit a similar notification in response to a request received from a different user to be added as an authorized user of the Net ID 271 (e.g., with their own device). In response to the notification, the authentication application 220 on the mobile device 101 of the user having previously established the Net ID 271 may be configured to prompt the user of the mobile device 101 to authorize the request, such as by signature of data (e.g., notification, request, Net ID, or other data indicating approval) within the TEE of the mobile device with the private key corresponding to the public key associated with the Net ID 271);
and maintain a record of authentication attempts, including timestamps, requesting device identifiers, and user responses (Avetisov on [0086, 0219-0221 and 0237] teaches marinating transaction record including timestamps, identifiers etc.).
Regarding claim 45 Avetisov teaches a tangible, non-transitory, machine-readable medium storing instructions that when executed by one or more processors of a computer system effectuate operations comprising: (Avetisov on [0014] teaches a tangible, non-transitory, machine-readable medium storing instructions that when executed by a data processing apparatus cause the data processing apparatus to perform operations);
obtaining, with a mobile device via an interaction with a computing device, a public credential associated with a credential pair corresponding with a user of the mobile device, the user of the mobile device being permitted to access a secure asset under an identity of the user of the mobile device (Avetisov Fig 1 block 101, 120 and text on [0067] teaches user mobile device executing authentication application 120 (i.e., authentication component). See on [0012] teaches identity record established within the decentralized data store, the identity record comprising a public key i.e., identity record comprising public credentials. See on [0044] teaches user is permitted to access secure asset in response to authenticating the user under established identity. See on [0037-0038] teaches User account information or records may include information about different computing devices used by the user (e.g., including a mobile computing device different from the client computing device attempting to access an online resource). See on [0095] teaches a user of the client device 135 may supply credentials 111 for accessing the secured asset. In one example, the secure asset is an online resource 147 on or accessible via one or more servers 145. See on [0117] teaches when a given client device (e.g., client device 135) attempts to access a secure asset in association with that user identifier, the authentication server 155 may create a device record (e.g., Device B) corresponding to the given client device under the UID Record 151 for that user identifier);
establishing, with the mobile device, a secure communication tunnel with a remote endpoint accessible by both the mobile device and the computing device, the remote endpoint being configured to relay authentication protocol messages between the mobile device and the computing device (Avetisov on [0053] teaches the computing environment 100 may include a mobile device 101, a client device 135, a relaying party 145, 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. In addition, embodiments of the example computing environment 100 may include a mobile computing client device, such as mobile device 101, that supports client-side out-of-band authentication based on a secure channel to a trusted execution environment);
initiating, with the mobile device, a broadcast over (Avetisov on [0034] teaches the remote server engages the authenticate service in response to an access attempt, receives a result subsequent to a user authenticating with the authentication service (e.g., with the mobile computing device), and authenticates a mobile device that engages the remote services based on the result. In some embodiments, the remote server may receive a result from the authentication service prior to a first access attempt. For example, a user may pre-authenticate on their mobile computing device with the authentication service. The result may be received by the remote server subsequent to the user authenticating with the authentication service (e.g., with the mobile computing device));
receiving, with the mobile device via the secure communication tunnel, an authentication request from the computing device, the authentication request comprising one or more challenge values
(Avetisov Fig 3B block 341 and text on [0238-0242] teaches authentication of a device with another device in an out-of-band authentication process, the process 300B begins with an access attempt by a client device (i.e., another device) at the relying party 145. The access attempt may be to a secure asset of the relying party 145, such as an online resource accessible by client devices over a network. The relying party 145 may pass information about the access attempt to the authentication server 155. The information passed to the authentication server 155 may include information such as user account information or device information associated with the access attempt. For example, the relying party 145 may receive a user account identifier at block 341 and pass the user account identifier to the authentication server 155. The authentication server 155, based on the user account identifier, may identify a UID Record 342. The UID record identified by the authentication server 155 may include records or a listing of one or more devices registered with the authentication server 155 for user authentication i.e., receiving user account identifier as selection to authenticate user based on user account identifier associated with UID record for authentication. Further teaches mobile device 101 having a trusted execution environment and previously registered with the authentication server 155, may receive the notification from the authentication server. Further teaches the notification may be determined responsive to information stored in the device record. For example, the device record may include a device identifier applicable to transmit the notification to the selected device. Similarly, the device record may store information about the different credentials which a user of the device may provide to authenticate with the authorization server using that device, the mobile device 101 may process 345 the notification within the trusted execution environment. The result of the processing 345 by the mobile device 101 may include various data transmitted to the authentication server 155 for authentication of the user of the mobile device);
creating, with the mobile device, an authentication response to the one or more challenge values using a private key stored within the mobile device, (Avetisov on [0176, 0217 and 0243] teaches the authentication server 155 may transmit a notification of the request received from the additional device to the mobile device 101. The authentication server 155 may also transmit a similar notification in response to a request received from a different user to be added as an authorized user of the Net ID 271 (e.g., with their own device). In response to the notification, the authentication application 220 on the mobile device 101 of the user having previously established the Net ID 271 may be configured to prompt the user of the mobile device 101 to authorize the request, such as by signature of data (e.g., notification, request, Net ID, or other data indicating approval) within the TEE of the mobile device with the private key corresponding to the public key associated with the Net ID 271);
wherein the one or more challenge values correspond to an authentication transaction initiated via a virtual device on a USB of a computing device, the virtual device presenting to an operating system of the computing device an interface of an external authenticator device (Avetisov on [0056-0057] teaches the mobile device 101 may be any client device, the mobile device may optionally include a trusted execution environment which, in some cases, may be an external, portable device capable of being coupled via a bus, like USB, to any client device including a suitable interface for authentication process. See on [0092 and 0159] teaches client device 135 may be a terminal device or otherwise configured to provide a user interface for terminal access to one or more computing devices or virtual machines that may include or provide access to a secure asset or be a secure asset themselves);
and transmitting, with the mobile device via the secure communication tunnel, the authentication response to the computing device, the authentication response comprising data that cryptographically demonstrates possession of the private key and successful authentication (Avetisov on [0243-0244] teaches he authentication server 155 may receive a response to the notification from the mobile device that includes data corresponding to representations of requested credentials input by the user or results of any verifications performed within the TEE. The response may also include signed data for verification of the data. For example, the authentication server 155 may use a public key for signature verification previously received from the mobile device 101 in a registration process to verify the data was generated by the mobile device having the corresponding private key. See on [0102] teaches the relying party server 145 may identify a user identifier or a device identifier stored within the UID repository 160 corresponding to the access attempt. In response to determining which user or device is attempting to access the secure asset, such as by determining one or more identifiers stored within the UID repository 160 corresponding to the access attempt, the relying party server 145 may transmit information about access attempt to the authentication server 155. The forwarded information may include the one or more identifiers determined from the UID repository 160 to correspond to the access attempt, in addition to information received from, or determined about, the client device 135. In turn, the relying party server 145 may receive an authentication result from the authentication server 155. The authentication result indicates whether the user of the client device 135 successfully authenticated with the authentication server 155 (e.g., via the mobile device 101). Based on the authentication result received from the authentication server 155, the relying party server 145 grants (in response to successful authentication) or denies (in response to unsuccessful authentication) the access attempt by the client device 135).
Avetisov fails to explicitly teach establishing wireless communication over a local wireless transport protocol, however ISHIMURA from analogous art teaches initiating, with the mobile device, a broadcast over (ISHIMURA on [0076-0077] teaches a communication may be detected from the second terminal apparatus 250 within a specific period of time from the establishment of the connection and the second terminal apparatus 250 may be nearer to the information processing apparatus 100 than the terminal apparatus 250. A determination as to whether the terminal apparatus 250 is nearer to the information processing apparatus 100 may be performed based on the strength of a radio wave received from the terminal apparatus. See on [0046 and 0086] teaches wireless communication module 195A (an example of a communication unit) performs a wireless communication with the terminal apparatus 250. The wireless communication may be Bluetooth, Bluetooth Low Energy (BLE), or Wi-Fi).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of ISHIMURA into the teaching of Avetisov by detecting communication from mobile device over local wireless transport protocol. One would be motivated to do so in order to establish secure communication between wireless devices over short-range communication based on detecting identification information in the communication detected by nearby device (ISHIMURA [0003-0007]).
Regarding claim 46 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 45 above, Avetisov further teaches further comprising validating the user of the mobile device, with the mobile device, based on a credential input received by the mobile device, the credential input comprising at least one of a biometric input, a personal identification number, or an alphanumeric password (Avetisov on [0139, 0182 and 0211] authenticating user using PIN or biometric. In response to obtaining a notification for processing, an authentication application 220 may interface with a TEE of the mobile device 101 to prompt the user to authenticate with the mobile device 101, such as by biometric authentication or entering credential values like a passcode, pin, or other values. In some embodiments, a notification may request authentication by one or more specific credential values or biometrics, which the user may supply for processing within the TEE. As described previously, credential values may reside with the user or within the TEE. For example, when the user authenticates on the mobile device 101 via a biometric value, the TEE may analyze the biometric values supplied by the user to determine whether the supplied biometric values are indicative of the user who established representations of those values within the TEE).
Regarding claim 49 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 45 above, Avetisov further teaches further comprising configuring, by the mobile device, a virtual device on a universal serial bus interface of the mobile device based on an advertisement initiated by the mobile device, wherein the virtual device is configured as a USB chip card interface device in response to the advertisement indicating a smart card authenticator service, or as a USB human interface device in response to the advertisement indicating a FIDO2 authenticator service (Avetisov on [0056 and 0275]).
Regarding claim 51 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 45 above, Avetisov further teaches wherein the short-range wireless communication interface of the mobile device comprises a Bluetooth Low Energy interface (ISHIMURA on [0046 and 0086] teaches the wireless communication may be Bluetooth, Bluetooth Low Energy (BLE), or Wi-Fi).
Regarding claim 52 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 45 above, ISHIMURA further teaches further comprising receiving, by the computing device, the broadcast from the mobile device over the short-range wireless communication interface, wherein the broadcast comprises data derived from a shared secret and is used by the computing device to validate physical proximity of the mobile device (ISHIMURA on [0076] teaches communication may be detected from the second terminal apparatus 250 within a specific period of time from the establishment of the connection and the second terminal apparatus 250 may be nearer to the information processing apparatus 100 than the terminal apparatus 250. The wireless communication control module 144 may perform control to enable the second terminal apparatus 250 to connect to the information processing apparatus 100 via the wireless communication module 195A. A determination as to whether the terminal apparatus 250 is nearer to the information processing apparatus 100 may be performed based on the strength of a radio wave received from the terminal apparatus 250. Specifically, if the strength of the radio wave received from the terminal apparatus 250 having established the connection (the terminal apparatus 250A) is higher than the strength of the radio wave received from the second terminal apparatus 250 (the terminal apparatus 250B), the terminal apparatus 250A is nearer to the information processing apparatus 100 than the terminal apparatus 250B. Conversely, if the strength of the radio wave received from the terminal apparatus 250B is higher than the strength of the radio wave received from the terminal apparatus 250A, the terminal apparatus 250B is nearer to the information processing apparatus 100 than the terminal apparatus 250A).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of ISHIMURA into the teaching of Avetisov by detecting communication from mobile device over local wireless transport protocol. One would be motivated to do so in order to establish secure communication between wireless devices over short-range communication based on detecting identification information in the communication detected by nearby device (ISHIMURA [0003-0007]).
Regarding claim 53 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 45 above, Avetisov further teaches further comprising, in response to receiving the authentication response, using the authentication response to authenticate a user of the mobile device to access a secure asset, wherein the secure asset comprises at least one of an application executed by the computing device, a user account of an operating system of the computing device, or an online resource accessible via the computing device (Avetisov on [0243-0244] teaches he authentication server 155 may receive a response to the notification from the mobile device that includes data corresponding to representations of requested credentials input by the user or results of any verifications performed within the TEE. The response may also include signed data for verification of the data. For example, the authentication server 155 may use a public key for signature verification previously received from the mobile device 101 in a registration process to verify the data was generated by the mobile device having the corresponding private key. See on [0102] teaches the relying party server 145 may identify a user identifier or a device identifier stored within the UID repository 160 corresponding to the access attempt. In response to determining which user or device is attempting to access the secure asset, such as by determining one or more identifiers stored within the UID repository 160 corresponding to the access attempt, the relying party server 145 may transmit information about access attempt to the authentication server 155. The forwarded information may include the one or more identifiers determined from the UID repository 160 to correspond to the access attempt, in addition to information received from, or determined about, the client device 135. In turn, the relying party server 145 may receive an authentication result from the authentication server 155. The authentication result indicates whether the user of the client device 135 successfully authenticated with the authentication server 155 (e.g., via the mobile device 101). Based on the authentication result received from the authentication server 155, the relying party server 145 grants (in response to successful authentication) or denies (in response to unsuccessful authentication) the access attempt by the client device 135).
Regarding claim 54 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 45 above, Avetisov further comprising displaying, on a user interface of the computing device, an option to select for authentication credentials to be supplied by a mobile device, the selection of the option operative to supply the public credential to the mobile device (Avetisov on [0049] teaches a requested authentication factor may be selected in response to criteria specified by the given authentication request and the criteria associated with the one or more prior authentication decisions. For example, if the criteria specified by the given authentication request specifies some authentication factor not previously provided in association with prior decisions, that factor may be selected. Similarly, an authentication factor may be selected based on that factor not being used in association with prior decisions. Alternatively, if each of the available authentication factors were used previously, the selected authentication factor may be different than at least the authentication factor used in association with the last decision. In some embodiments, selection of an authentication factor for re-authentication may be from a subset of factors that are less intrusive to user experience, like a biometric input or a PIN rather than a lengthy password. In contrast, for an initial or full authentication, a stronger authentication factor (which may be a combination of authentication factors) may be requested, and the stronger authentication factor may optionally be requested along with one or more authentication factors selected from the subset of factors for re-authentication)
Claim 44 is rejected under 35 U.S.C. 103 as being unpatentable over Avetisov et al (hereinafter Avetisov) (US 20200067907) in view of ISHIMURA (US 20220308809) and further in view Boliek et al (hereinafter Boliek) (US 20210021988).
Regarding claim 44 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 21 above, Avetisov further teaches the private credential and public credential are generated by an asymmetric encryption protocol (Avetisov on [0068] teaches the use of asymmetric encryption algorithms, like those utilizing key exchanges, can afford secure communications without requiring a secure channel. One example of such an asymmetric encryption algorithm generates a key-pair for an entity, where a first key of the key-pair is a private key (e.g., held securely by the entity) operable to decrypt data encrypted with a second key of the key-pair and the second key is a public key made available to other entities for encrypting data to be transmitted to the entity having the private key. However, such asymmetric encryption algorithms are computationally intensive and inefficient for high frequency communications oror communications of increasing data size. Thus, in many instances, it is preferable to communicate securely, but also efficiently, such as over a secure channel, using symmetric encryption algorithms that are less computationally intensive than asymmetric ones).
The combination fails to explicitly teach detecting the broadcast by the other device comprises detecting a signal advertising a FIDO2 or Smart Card authenticator on a wireless communication interface with a device discovery service or a zero-configuration networking protocol, however Boliek from analogous art teaches
wherein: detecting the broadcast by the other device comprises detecting a signal advertising a FIDO2 or Smart Card authenticator on a wireless communication interface with a device discovery service or a zero-configuration networking protocol (Boliek on [0021, 0078 and 0101-0102] teaches communication between device using zero configuration network protocol).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Boliek into the combined teaching of Avetisov and ISHIMURA byutilizing zero-configuration network protocol for communication between device. One would be motivated to do so in order to automatically form network between devices and to eliminate the need of manual network configuration (Boliek [0021 and 0140]).
Claims 47-48 are rejected under 35 U.S.C. 103 as being unpatentable over Avetisov et al (hereinafter Avetisov) (US 20200067907) in view of ISHIMURA (US 20220308809) and further in view Malzhn et al (hereinafter Malzhn) (US 20120246404).
Regarding claim 47 the combination of Avetisov and ISHIMURA teaches all the limitations of claims 45 above, the combination fails to explicitly teach creating the authentication response further comprises translating, by the mobile device, data formatted in accordance with a USB human interface device protocol into a message formatted in accordance with a client-to- authenticator protocol, however Malzahn from analogous art teaches
wherein creating the authentication response further comprises translating, by the mobile device, data formatted in accordance with a USB human interface device protocol into a message formatted in accordance with a client-to- authenticator protocol (Malzahn on [0055-0058] teaches manage the transmission and lower protocols using, for example, ISO/IEC 14443, ISO/IEC 7816, and USB protocols).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Malzahn into the combined teaching of Avetisov and ISHIMURA by formatting accordance with a USB human interface. One would be motivated to do so in order to establish secure communication between wireless devices and control overall communications within the smart card based in authentication protocol (Malzahn [0003-0004]).
Regarding claim 48 the combination of Avetisov, ISHIMURA and Malzahn teaches all the limitations of claims 47 above, Malzahn further teaches wherein the client-to-authenticator protocol comprises a smart card authentication protocol compliant with at least one of ISO/IEC 7816 or NIST Special Publication 800-73-4 (Malzahn on [0055-0058] teaches manage the transmission and lower protocols using, for example, ISO/IEC 14443, ISO/IEC 7816, and USB protocols).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Malzahn into the combined teaching of Avetisov and ISHIMURA by formatting accordance with a USB human interface. One would be motivated to do so in order to establish secure communication between wireless devices and control overall communications within the smart card based in authentication protocol (Malzahn [0003-0004]).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 MOEEN KHAN whose telephone number is (571)272-3522. The examiner can normally be reached 7AM-5PM EST M-TH Alternate Fridays.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Shewaye Gelagay can be reached on (571)272-4219. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/MOEEN KHAN/ Primary Examiner, Art Unit 2436