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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on October 15, 2024 has been considered by the examiner.
Drawings
The drawing submitted on November 20, 2024 has been accepted and considered.
Specification
The specifications submitted on November 20, 2024 has been accepted and considered.
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 s 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "the own authentication device" in line 8.
Claim 8 recites the limitation "the own authentication device" in line 7.
Claim 9 recites the limitation "the authentication device" in line 3.
Claim 9 recites the limitation "the own authentication device" in line 8.
Claim 11 recites the limitation "the own authentication device" in line 4.
There is insufficient antecedent basis for this limitation in the claims.
Dependent claims 2-7 and 10-20 failed to remedy the deficiencies of their respective independent claims. Therefore, claims 1-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor regards as the invention.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-14 are rejected under 35 U.S.C. 103 as being unpatentable over Salajegheh et al. (US 20210409405 A1 –hereinafter—Salajegheh) in view of Agrawal al et (US 20210336792 A1 –hereinafter—Agrawal).
As per claim 1. Salajegheh discloses an authentication device belonging to an authentication system including N authentication devices, where N is an integer constant equal to or greater than 2 ([0128] The first authentication device 210, the Nth authentication device 212, the initiator device 220, and the user device 230 can be all be user devices, as they are owned and/or operated by a user. These devices (i.e., the first authentication device 210, the Nth authentication device 212, the initiator device 220, and the user device 230) can include electronic devices, the authentication device comprising:
an authentication unit that executes authentication processing of an authentication object based on information of the authentication object (Examine Notes authentication object is as authentication token [0058] devices can use proximity checking to identify peer devices that are present nearby, apply anomaly detection to determine which of these proximal peers are trustworthy, participate in a series of threshold MAC schemes with the trusted devices, and finally compute an authentication token that captures the number of devices participating (expressed as a cryptographic threshold), the trust shared among these devices (expressed as an assurance level), and information about the authentication request itself (user name for the account, level of authentication needed, etc.) [0081] The initiator device can launch a request to all of the present user devices for the joint computation of an authentication token. Each user device receiving the request can determine whether to participate in this joint computation depending on their own trust score for the initiator device and their own trust scores for the other present user devices. For example, if there are a total of five user devices present (including the initiator device), but the initiator device is trusted by two other user devices, then three user devices can jointly compute an authentication token. The authentication token can reflect the number of user devices that participated in its computation. [0082] Once the initiator device and the participating user devices compute the authentication token, the initiator device can provide the authentication token to the web browser, which can send the authentication token to the authentication server. Now, the authentication server has several pieces of evidence for the user's identity: the password entered in the browser, the device identity of the initiator device, and the authentication token defining the number of participating user devices. These items are then used to make an authentication decision, such as process a request, proceed with a payment transaction, allow access to a secure system and/or location); and
a communication unit that transmits the information via a network to at least one of (N−1) other authentication devices which are of the N authentication devices and are other than the own authentication device ([0123-0126] FIG. 2 System 200 comprises a first authentication device 210 through an Nth authentication device 212, an initiator device 220, a user device 230, and an authentication server 240. The first authentication device 210 can be in operative communication with the Nth authentication device 212. In some embodiments, there can be any suitable number of authentication devices, e.g., 3, 4, 5, 10, etc. Each authentication device can be in operative communication with one another. The initiator device 220 can be in operative communication with each authentication device (e.g., the first authentication device 210 and the Nth authentication device 212) as well as the user device 230. In some embodiments, the initiator device 220 can be in operative communication with the authentication server 240. The user device 230 can be in operative communication with the initiator device 220 as well as the authentication server 240).
Salajegheh does not explicitly disclose the information of the authentication object is an authentication information. Agrawal, in analogous art however, discloses the information of the authentication object is an authentication information ([0029-0030] FIDO Universal Authentication Framework/architecture that proposes a way to authenticate a device to an authentication server ([0024] Most users own and carry multiple devices, such as their laptop, smartphone, and smartwatch, and have other Internet of Things devices around when authenticating such as their smart TV or smart-home appliances. Embodiments provide a new framework for client-side biometric-based authentication with the goal of distributing both the biometric templates as well as the secret signing key among multiple devices who collectively perform the biometric matching and signature generation without ever reconstructing the template or the signing key on one device. This framework may be referred to as Fuzzy Threshold Token Generation (FTTG). FTTG can also be used to protect biometric information on the server-side by distributing it among multiple servers who perform the matching and token generation (e.g. for a single sign-on authentication token) in a fully distributed manner. [0025] During a one-time registration phase, both the template and the signing key are distributed among n devices, among which any t of them can generate tokens. The exact values of n and t are parameters of the scheme and vary across different protocols. Then, during each authentication session, the initiating device obtains the biometric measurement and exchanges a constant number of messages with t−1 other devices in order to verify that the biometric measurement is close enough, with respect to some distance measure, to the secret shared template and if yes, obtain a token, which may also be referred to as a digital signature, on a message chosen by the initiating parties. [0036] During the registration phase the user can enter biometric data into the user device 110. For example, the user may use a camera of the user device 110 to take a picture of their face. A biometric template (e.g., a facial scan) can be extracted from the biometric data and stored “securely” inside the user device 110. At the same time, the secret key/public key pair can be generated. The public key can be communicated with the authentication server 140 whereas the secret key is securely stored in the user device 110. The secret key is virtually “locked” with the template. Later, during sign-on, a candidate template is used to unlock the secret key, which can then used in a standard identification protocol). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of information of the authentication object disclosed by Salajegheh to is an authentication information. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a robust and enhanced method to measures biometric features of the user to obtain a measurement vector, and sends the measurement vector and a challenge message to the other devices and a first device receives partial computations, generated using a respective template share, key share, and the challenge message, from the other devices, uses them to generate a signature of the challenge message and send the signature to a second device as suggested by Agrawal ([0006-0007]).
As per claim 2. Salajegheh in view of Agrawal discloses the authentication device according to claim 1, wherein the communication unit transmits the authentication information to at least one of the (N−1) other authentication devices when authentication by the authentication unit is successful (Agrawal [0025] We initiate a formal study of FTTG and introduce a number of concrete protocols secure within the framework. In protocols according to embodiments, during a one-time registration phase, both the template and the signing key are distributed among n devices, among which any t of them can generate tokens. The exact values of n and t are parameters of the scheme and vary across different protocols. Then, during each authentication session, the initiating device obtains the biometric measurement and exchanges a constant number of messages with t−1 other devices in order to verify that the biometric measurement is close enough, with respect to some distance measure, to the secret shared template and if yes, obtain a token, which may also be referred to as a digital signature, on a message chosen by the initiating parties).
As per claim 3. Salajegheh in view of Agrawal discloses the authentication device according to claim 1, wherein the authentication unit authenticates the authentication object by using the authentication information of the authentication object acquired from at least one of the (N−1) other authentication devices via the communication unit (Agrawal [0025] We initiate a formal study of FTTG and introduce a number of concrete protocols secure within the framework. In protocols according to embodiments, during a one-time registration phase, both the template and the signing key are distributed among n devices, among which any t of them can generate tokens. The exact values of n and t are parameters of the scheme and vary across different protocols. Then, during each authentication session, the initiating device obtains the biometric measurement and exchanges a constant number of messages with t−1 other devices in order to verify that the biometric measurement is close enough, with respect to some distance measure, to the secret shared template and if yes, obtain a token, which may also be referred to as a digital signature, on a message chosen by the initiating parties).
As per claim 4. Salajegheh in view of Agrawal discloses the authentication device according to claim 1, further comprising: a storage unit that stores the authentication information of the authentication object and cooperation information between the N authentication devices, wherein the communication unit transmits the authentication information to at least one of the (N−1) other authentication devices based on the cooperation information stored in the storage unit (Salajegheh [0141] FIG. 4 shows token shares received by an initiator device 400. The initiator device 400 can be the smart phone 340. The smart phone 340 can receive token shares from authentication devices such as the smart watch 310, the voice-controlled assistant 320, and the smart TV 330, labeled as authentication device 1, authentication device 2, and authentication device 3, respectively. Each token share that the smart phone 340 receives can be associated with an assurance level. The token shares shown can be stored, for example, in a memory or other suitable storage component).
As per claim 5. Salajegheh in view of Agrawal discloses the authentication device according to claim 4, further comprising: a management unit that manages the cooperation information including information of an expiration date and the authentication information of the authentication object, wherein the management unit deletes the cooperation information having a passed expiration date (Salajegheh [0227] Given some already registered user devices, the following steps described how to add a new user device D. 1) The user can log into a user device management portal using their username and password. 2) D can run a discovery algorithm to find its neighbors (i.e., peer user devices) on the same network. 3) D can act as an initiator device, as described herein, and can contact nearby user devices to be authentication devices for registration. 4) Each of the already registered user devices can show a “permission request for new user device” pop-up which the user has to confirm).
As per claim 6. Salajegheh in view of Agrawal discloses the authentication device according to claim 4, wherein the cooperation information includes at least one of a transmission destination of the authentication information, an environmental parameter, a personal parameter, and a position parameter (Salajegheh [0184] Features such as packet size, destination, source, number of bytes received per second, number of authentication requests, time of requests, parameters of the authentication request can improve the accuracy of finding malicious activity and perceiving an accurate trust score about a device's neighbors).
As per claim 7. Salajegheh in view of Agrawal discloses the authentication device according to claim 1, wherein the authentication information is a feature extracted from the authentication object or a registered feature extracted in advance from the authentication object and registered (Salajegheh [0080] When the user attempts to authenticate to the authentication server, for example, by entering their password in a web browser, the web browser can connect to one of registered user devices via a local communication scheme (e.g., over WebAuthn [24]). This user device, referred to as the initiator device for the duration of an authentication operation, can discover all other registered user devices in close proximity. The locally available user devices together with the initiator device can form the set of present user devices).
As per claim 8. Claim 8 is directed to an authentication method performed by an authentication device belonging to an authentication system including N authentication devices, N is an integer constant equal to or greater than 2, the authentication method having substantially similar claimed limitations corresponding to claim 1 and therefore claim 8 is rejected with the same rationale given above to reject claim 1.
As per claim 9. Salajegheh discloses an authentication system comprising:
a server device ([0040] An “authentication server” can include a server capable of authentication. An authentication server can be operated by an authenticator which can include an entity capable of authentication. In some embodiments, the authenticator can include an entity that offers services and authenticates a user for the service by verifying a token); and
N authentication devices, N is an integer constant equal to or greater than 2, wherein the authentication device ([0123-0126] FIG. 2 System 200 comprises a first authentication device 210 through an Nth authentication device 212, an initiator device 220, a user device 230, and an authentication server 240. The first authentication device 210 can be in operative communication with the Nth authentication device 212. In some embodiments, there can be any suitable number of authentication devices, e.g., 3, 4, 5, 10, etc. Each authentication device can be in operative communication with one another. The initiator device 220 can be in operative communication with each authentication device (e.g., the first authentication device 210 and the Nth authentication device 212) as well as the user device 230. In some embodiments, the initiator device 220 can be in operative communication with the authentication server 240. The user device 230 can be in operative communication with the initiator device 220 as well as the authentication server 240), and
executes authentication processing of an authentication object based on information of the authentication object (Examine Notes authentication object is as authentication token [0058] devices can use proximity checking to identify peer devices that are present nearby, apply anomaly detection to determine which of these proximal peers are trustworthy, participate in a series of threshold MAC schemes with the trusted devices, and finally compute an authentication token that captures the number of devices participating (expressed as a cryptographic threshold), the trust shared among these devices (expressed as an assurance level), and information about the authentication request itself (user name for the account, level of authentication needed, etc.) [0081] The initiator device can launch a request to all of the present user devices for the joint computation of an authentication token. Each user device receiving the request can determine whether to participate in this joint computation depending on their own trust score for the initiator device and their own trust scores for the other present user devices. For example, if there are a total of five user devices present (including the initiator device), but the initiator device is trusted by two other user devices, then three user devices can jointly compute an authentication token. The authentication token can reflect the number of user devices that participated in its computation. [0082] Once the initiator device and the participating user devices compute the authentication token, the initiator device can provide the authentication token to the web browser, which can send the authentication token to the authentication server. Now, the authentication server has several pieces of evidence for the user's identity: the password entered in the browser, the device identity of the initiator device, and the authentication token defining the number of participating user devices. These items are then used to make an authentication decision, such as process a request, proceed with a payment transaction, allow access to a secure system and/or location);
the authentication device transmits and receives the information to and from the server device, or to and from at least one of (N−1) other authentication devices which are of the N authentication devices and are other than the own authentication device (([0128] The first authentication device 210, the Nth authentication device 212, the initiator device 220, and the user device 230 can be all be user devices, as they are owned and/or operated by a user. These devices (i.e., the first authentication device 210, the Nth authentication device 212, the initiator device 220, and the user device 230) can include electronic devices. [0130] The authentication server 240 can be a server computer. At step 1, the authentication server 240 can be configured to receive credentials, such as a username and a password, from the user device 230. At step 2, the authentication server 240 can also be configured to generate and transmit a challenge request to the user device 230. In some embodiments, the challenge request can request additional authentication for the user beyond the credentials. At step 7, the authentication server 240 can also be configured to receive and verify an authentication token. [0131] The user device 230 can be configured to receive the credentials from a user and then transmit, at step 1, the credentials to the authentication server 240. The user device 230 can also be configured to receive, at step 2, the challenge request from the authentication server 240 and forward, at step 3, the challenge request to the initiator device 220. [0132] At step 3, the initiator device 220 can be configured to receive the challenge request as well as generate a witness request. In some embodiments, the witness request can include a request for token shares. At step 4, the initiator device 220 can broadcast the witness request to one or more authentication devices (i.e., the first authentication device 210 and the Nth authentication device 212). The initiator device 220 can also be configured to receive, at step 5, at least one witness response comprising a token share and an assurance level from one or more authentication devices. Typically, the initiator device 220 can receive the witness response from each of the one or more authentication devices. However, the imitator device 220 may not receive the witness response from an authentication device due to any number of reasons, such as lost connection, the authentication device lost power, etc. Each witness response can comprise more than one token share, where each token share corresponds to a unique assurance level. For example, the witness response can include three token shares, each of the three token shares corresponding to a different assurance level).
Salajegheh does not explicitly disclose the information of the authentication object is an authentication information. Agrawal, in analogous art however, discloses the information of the authentication object is an authentication information ([0029-0030] FIDO Universal Authentication Framework/architecture that proposes a way to authenticate a device to an authentication server ([0024] Most users own and carry multiple devices, such as their laptop, smartphone, and smartwatch, and have other Internet of Things devices around when authenticating such as their smart TV or smart-home appliances. Embodiments provide a new framework for client-side biometric-based authentication with the goal of distributing both the biometric templates as well as the secret signing key among multiple devices who collectively perform the biometric matching and signature generation without ever reconstructing the template or the signing key on one device. This framework may be referred to as Fuzzy Threshold Token Generation (FTTG). FTTG can also be used to protect biometric information on the server-side by distributing it among multiple servers who perform the matching and token generation (e.g. for a single sign-on authentication token) in a fully distributed manner. [0025] During a one-time registration phase, both the template and the signing key are distributed among n devices, among which any t of them can generate tokens. The exact values of n and t are parameters of the scheme and vary across different protocols. Then, during each authentication session, the initiating device obtains the biometric measurement and exchanges a constant number of messages with t−1 other devices in order to verify that the biometric measurement is close enough, with respect to some distance measure, to the secret shared template and if yes, obtain a token, which may also be referred to as a digital signature, on a message chosen by the initiating parties. [0036] During the registration phase the user can enter biometric data into the user device 110. For example, the user may use a camera of the user device 110 to take a picture of their face. A biometric template (e.g., a facial scan) can be extracted from the biometric data and stored “securely” inside the user device 110. At the same time, the secret key/public key pair can be generated. The public key can be communicated with the authentication server 140 whereas the secret key is securely stored in the user device 110. The secret key is virtually “locked” with the template. Later, during sign-on, a candidate template is used to unlock the secret key, which can then used in a standard identification protocol). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of information of the authentication object disclosed by Salajegheh to is an authentication information. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a robust and enhanced method to measures biometric features of the user to obtain a measurement vector, and sends the measurement vector and a challenge message to the other devices and a first device receives partial computations, generated using a respective template share, key share, and the challenge message, from the other devices, uses them to generate a signature of the challenge message and send the signature to a second device as suggested by Agrawal ([0006-0007]).
As per claim 10. Salajegheh in view of Agrawal discloses the authentication system according to claim 9, wherein the server device executes the authentication processing of the authentication object by using the authentication information transmitted from the authentication device (Salajegheh [0058] Except for an assurance level that can accompany an authentication token, no other information about the devices or the user is sent to the authentication server. In some embodiments, devices can use proximity checking to identify peer devices that are present nearby, apply anomaly detection to determine which of these proximal peers are trustworthy, participate in a series of threshold MAC schemes with the trusted devices, and finally compute an authentication token that captures the number of devices participating (expressed as a cryptographic threshold), the trust shared among these devices (expressed as an assurance level), and information about the authentication request itself (user name for the account, level of authentication needed, etc.). Thus the privacy-preserving authentication scheme according to embodiments of the disclosure scales to any number of factors, provides risk information, and maintains the usability of seamless authentication).
As per claim 11. Salajegheh in view of Agrawal discloses the authentication system according to claim 9, wherein the authentication device transmits the authentication information to at least one of the (N−1) other authentication devices when at least one of the authentication processing of the authentication object by the own authentication device and authentication processing of the authentication object by the server device is successful (Agrawal [0025] We initiate a formal study of FTTG and introduce a number of concrete protocols secure within the framework. In protocols according to embodiments, during a one-time registration phase, both the template and the signing key are distributed among n devices, among which any t of them can generate tokens. The exact values of n and t are parameters of the scheme and vary across different protocols. Then, during each authentication session, the initiating device obtains the biometric measurement and exchanges a constant number of messages with t−1 other devices in order to verify that the biometric measurement is close enough, with respect to some distance measure, to the secret shared template and if yes, obtain a token, which may also be referred to as a digital signature, on a message chosen by the initiating parties).
As per claim 12. Salajegheh in view of Agrawal discloses the authentication system according to claim 9, wherein the server device and the N authentication devices have cooperation information between the server device and the N authentication devices (Salajegheh [0132] At step 3, the initiator device 220 can be configured to receive the challenge request as well as generate a witness request. In some embodiments, the witness request can include a request for token shares. At step 4, the initiator device 220 can broadcast the witness request to one or more authentication devices (i.e., the first authentication device 210 and the Nth authentication device 212). The initiator device 220 can also be configured to receive, at step 5, at least one witness response comprising a token share and an assurance level from one or more authentication devices).
As per claim 13. Salajegheh in view of Agrawal discloses the authentication system according to claim 12, wherein the cooperation information includes at least one of a transmission destination of the authentication information, an environmental parameter, a personal parameter, and a position parameter (Salajegheh [0163] The network data can affect the trust score. For example, the trust score module 612A can determine a lower trust score for an initiator device (i.e., that it is less trustworthy) if the network data indicates that the initiator device has much higher than average transmission rates (e.g., the initiator device transmits 3-10 times more data than other devices). As another example, if the network data indicates that an initiator device has low data reception rates, then the trust score module 612A can determine a lower trust score, since the initiator device is not receiving messages from other devices. For example, this can indicate that other devices do not trust the initiator device).
As per claim 14. Salajegheh in view of Agrawal discloses the authentication system according to 12, wherein the server device or the authentication device succeeded in the authentication processing of the authentication object retains at least one of a feature extracted from the authentication object or a registered feature extracted in advance from the authentication object and registered (Salajegheh [0180] Devices that are registered devices 710 can be include in the present devices 720 and/or the trusted devices 740. If a devices is registered, present, and trusted, then the devices can be included in the devices used for authentication 730. [0178] FIG. 7 shows classes of devices according to embodiments of the disclosure. FIG. 7 includes registered devices 710, present devices 720, devices used for authentication 730, and trusted devices 740. FIG. 7 illustrates that the present devices 720, the devices used for authentication 730, and the trusted devices 740 are all within the registered devices 710. If a devices is not registered, then the devices may not participate in an authentication process and may not be considered present and trusted).
Claims 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Salajegheh et al. (US 20210409405 A1 –hereinafter—Salajegheh) in view of Agrawal al et (US 20210336792 A1 –hereinafter—Agrawal) in further view of Ando US 20180176417 A1
As per claim 15. Salajegheh and Agrawal does not explicitly disclose wherein the cooperation information includes expiration date information of the cooperation information. Ando, in analogous art however, discloses wherein the cooperation information includes expiration date information of the cooperation information ([0074] The authentication service unit 22 authenticates the tenant ID, SUID, and SPWD, each included in the acquisition request. Said differently, the authentication service unit 22 determines whether a group of the tenant ID, SUID, and SPWD is stored in the user information memory unit 23. In a case where this group is stored in the user information memory unit 23, the authentication is successful. Otherwise, the authentication is failed. In a case where the authentication is successful, the authentication service unit 22 generates the access token, and causes the access token and the expiry date of the access token to be stored in association with SUID into the user information memory unit 23, for example. The authentication service unit 22 returns the access token and the expiry date of the access token to the authentication collaborating unit 126 (S114). The authentication collaborating unit 126 adds the access token and the expiry date of the access token to the target access information. In a case where SUID is not included in the target access information, the authentication collaborating unit 126 adds this SUID to the target access information. The authentication collaborating unit 126 further adds the app ID of the app 121a to the permission list of the target access information. These renewals of the target access information are reflected on the access information memory unit 134. Meanwhile, in a case where the authentication is failed, the access token is not returned but information indicating the failed authentication is returned in step S114). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the cooperation information disclosed by Salajegheh and Agrawal to include wherein includes expiration date information of the cooperation information. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide multiple external services and interfaces to facilitate management of interfaces as suggested by Ando ([0007]).
As per claim 16. Salajegheh in view of Agrawal in further view of Ando discloses the authentication system according to claim 15, wherein the server device and the N authentication devices delete the cooperation information having a passed expiration date based on the expiration date information (Salajegheh [0230] In removing a user device (i.e., performing a Remove( ) method), all user devices (i.e., in proximity or remote) can be notified to remove that user device from their list of registered user devices. The user devices can also set the trust score associated with the removed user device to zero. If the user is removing a user device, then the removed user device can be wiped clean, thus any key shares can be removed from memory. However, if the removed user device is stolen, the key shares for all levels can be updated on the authenticator side (i.e., by the authentication server) and on the user devices as well. Updating the keys for all user devices may not be efficient, however this is task will not occur frequently).
As per claim 17. Salajegheh in view of Agrawal discloses the authentication system according to claim 12, wherein the server device and the N authentication devices change the cooperation information based on a predetermined condition ([0052] Devices normally used every day have sufficient information about their user to collaboratively provide evidence to the user's (digital) identity. Moreover, multiple devices allow for redundancy by removing any single point of failure. Embodiments provide a new frictionless way to identify users with user devices. A visual comparison of embodiments, various embodiments collectively referred to as collaborative risk-aware authentication (CoRA), against other MFA and 2FA schemes is shown in FIG. 1).
As per claim 18. Salajegheh in view of Agrawal discloses the authentication system according to claim 16, wherein the server device and the N authentication devices change the cooperation information based on personal information of the authentication object who uses the authentication system ([0052] These devices range from smartphones, laptops, tablets, smart TVs, game consoles, voice-controlled assistants, connected cars, e-readers, activity/fitness trackers, smartwatches, to smart-home devices (refrigerators, thermostat, camera). Devices normally used every day have sufficient information about their user to collaboratively provide evidence to the user's (digital) identity. Moreover, multiple devices allow for redundancy by removing any single point of failure. Embodiments provide a new frictionless way to identify users with user devices).
As per claim 19. Salajegheh in view of Agrawal discloses the authentication system according to claim 12, wherein a condition defining the cooperation information is attributed to the authentication object ([0139] If the user devices (e.g., the smart watch 310, the voice-controlled assistant 320, and the smart TV 330) trust the smart phone 340 (as determined using trust scores) as well as determine that the smart phone 340 is in proximity, the authentication devices can collaborate with the smart phone 340 to generate a MAC (e.g., an authentication token) for the challenge. At step 5, the smart watch 310, the voice-controlled assistant 320, and the smart TV 330 can transmit token shares to the smart phone 340).
As per claim 20. Salajegheh in view of Agrawal discloses the authentication system according to claim 12, wherein the authentication device transmits and receives, based on the cooperation information, a plurality of types of authentication information to be used in multi-factor authentication to and from the server device configured to execute the multi-factor authentication ([0049] Current authentication techniques face a trade-off of security versus usability. Two factor authentication, for example, is one way to improve security at the cost of requiring user interaction for every round. Most 2FA methods are bound to a user's phone and fail if the phone is not available. Embodiments of the disclosure allow for a seamless and risk-aware authentication method that can take advantage of devices that the user owns. [0054] Seamless authentication addresses the usability challenge of MFA by having the various devices communicate with each other to exchange the needed information (the evidence of identity), after the successful establishment of proximity among the devices.)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
JACOBSON (US 20110305333) discloses a method for a client node to establish a session key with a group node by obtaining an epoch identity value associated with a current epoch, wherein obtaining the epoch identity value includes one of computing the epoch identity value based on a node real time or negotiating the epoch identity value with the group node, computing a restricted key using a shared secret key, the epoch identity value, and a group node identity associated with the group node, and executing a session key establishment protocol with the group node to derive the session key using the restricted key as a master key in the session key establishment protocol. The session key may be established between the group node and the client node even though communications between the group node and the central node is only intermittently available during the current epoch.
Mohassel (US 20210243026 ) discuses methods and systems of password-based threshold authentication, which distributes the role of an authentication server among multiple servers. Any t servers can collectively verify passwords and generate authentication tokens, while no t−1 servers can forge a valid token or mount offline dictionary attacks.
BRI (Broadest Reasonable Interpretation) Considerations
The above claims under examination have been given to them their BRI considerations consistent with the applicant’s disclosure as they would be interpreted by ordinary skill in the art (POSITA) at the time of filing of the invention. In order to construe, appraise boundary and scope of the claimed limitations, the following claim words or terms or phrases or languages have been given to them their BRI considerations and context in view of the applicant’s disclosure. For record clarity, BRI for the following claim words or terms or phrases or languages, the examiner recites descriptions from the applicant’s disclosure as follows:
The authentication processing of the authentication object based on the authentication information of the authentication object:
[0042] The verification determination processing unit 1034 performs verification determination of a person based on the registered feature acquired from the feature database management unit 1031 and/or the extracted feature extracted by the feature extraction unit 1035. That is, the verification determination processing unit 1034 executes the authentication processing of the authentication object based on the authentication information of the authentication object. The verification determination processing unit 1034 may perform multi-factor authentication.
[0055] The verification determination processing unit 2023 performs verification determination of a person based on the feature data acquired from the feature database management unit 2021. The verification determination processing unit 2023 may perform multi-factor authentication in which authentication processing is performed by using a plurality of types of authentication information (for example, face image data for face authentication and fingerprint data for fingerprint authentication). The verification determination processing unit 2023 transmits a result of the verification determination to the communication I/F 200.
[0154] The inter-client cooperation information according to the present embodiment includes at least one of a transmission destination of the authentication information, an environmental parameter, a personal parameter, and a position parameter. Accordingly, the client authentication terminal 10 can efficiently share the authentication information with other client authentication terminals based on the respective parameters of the inter-client cooperation information.
[0155] The authentication information according to the present embodiment is an extracted feature extracted from the authentication object or a registered feature extracted in advance from the authentication object and registered. Accordingly, the client authentication terminal 10 can execute the authentication processing of the authentication object based on the extracted feature or the registered feature.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
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, LINGLAN EDWARDS can be reached at (571) 270-5440. 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.
/TECHANE GERGISO/ Primary Examiner, Art Unit 2408
Prosecution Insights