DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to the Amendment filed on 7/24/2025.
In instant Amendment, claims 1, 9, 12, 21 and 23 have been amended; claim 2 has been canceled and claims 1, 9 and 21 are independent claims. Claims 1, 3-25 and 21-26 have been examined and are pending. This Action is made Final.
The examiner notes the IDS(s) filed on 4/22/2025 and 10/22/2025 have been considered.
Response to Arguments
Applicant’s arguments with respect to the 35 U.S.C. 102/103 rejection have been considered but are moot in view of the new ground(s) of rejection.
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.
Claim(s) 1, 7, 15 and 25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gehret et al. (US 9,608,970 B1) in view of Kwok et al. (US 2022/0141215 A1) and Weiss et al. (US 2021/0165898 A1).
Regarding Claim 1;
Gehret discloses one or more non-transitory, computer-readable media having instructions that, when executed by one or more processors of an origination device (FIG. 11 – Requester (1102)), cause the origination device to:
detect a user indication of an access credential to be shared with a recipient device (FIG. 3 and FIG. 4 and FIG. 11 and col. 10, lines 10-28 - Referring again to FIG. 4, in some implementations, the user interface 400 can also include a control 406 that enables the user to share the selected “key” with another user by selecting the icon 406. Selecting the icon 406 can launch another interface that allows the user to share the selected “key” with one or more other users and col. 10, lines 29-35 - In some implementations, when a user activates the control 604, the user interface 610 shown in FIG. 6B can be provided, to allow the user to share the key with another user. In some implementations, activation of the control 604 can initiate transmission of a request to a remote server (e.g., a server associated with the credential management system) to provide one or more shareable representations of the key.), the access credential to provide access to a secured entity (FIG. 3-5 and FIG. 11 and col. 9, lines 40-47 - FIG. 3 shows an illustration of an example of a user interface 300 that enables a user to manage one or more keys associated with a credential. The user interface 300 includes one or more keys (e.g., the key 302 that allows an access to the headquarter (HQ) 12.sup.th Lobby South, the key 312 that allows access to the HQ elevators, and the key 314 that allows access to the HQ garage) associated with a particular credential and col. 9, lines 55-56 - FIG. 4 shows an illustration of an example user interface 400 that enables a user to access a resource using a key. The user interface 400 can be displayed when a user selects the key 302 shown in FIG. 3.);
obtain a token corresponding to the access credential from [a] credential manager (FIG. 1 and FIG. 3 and FIG. 4 and FIG. 11 and col. 8, lines 32-43 - FIG. 1 shows a sample user interface 100 that enables a user to select from among various credentials of the user. The interface 100 can be provided as a part of a credential management application that allows a user to create a user-account and manage credentials that may be associated with the user account. In some implementations, the various credentials may be issued by different organizations. In particular, the user interface 100 includes an example of a user's wallet (identified with a “User Wallet” caption 102) that provides the user with access to numerous different credentials associated with the user and col. 9, lines 40-47 - FIG. 3 shows an illustration of an example of a user interface 300 that enables a user to manage one or more keys associated with a credential);
generate [a representation] of the token (col. 10, lines 29-42 - In some implementations, when a user activates the control 604, the user interface 610 shown in FIG. 6B can be provided, to allow the user to share the key with another user. In some implementations, activation of the control 604 can initiate transmission of a request to a remote server (e.g., a server associated with the credential management system) to provide one or more shareable representations of the key. In some implementations, the shareable representations may also be generated locally at the client device of the user initiating the key-sharing. In such a case, the client device generating the representation of the key may transmit information about the generated representation to a remote entity (e.g., the server associated with the credential management system) that validates a use of the key.),
provide the token and the [representation] to a relay server for storage (col. 10, lines 29-42 - In some implementations, when a user activates the control 604, the user interface 610 shown in FIG. 6B can be provided, to allow the user to share the key with another user. In some implementations, activation of the control 604 can initiate transmission of a request to a remote server (e.g., a server associated with the credential management system) to provide one or more shareable representations of the key. In some implementations, the shareable representations may also be generated locally at the client device of the user initiating the key-sharing. In such a case, the client device generating the representation of the key may transmit information about the generated representation to a remote entity (e.g., the server associated with the credential management system) that validates a use of the key and col. 14, lines 39-64 - In operation, the server 1106 manages and/or stores one or more credentials, associates users, groups of users, and keys with appropriate credentials, and provides the credentials and keys to users' client devices to allow the users to access various physical and virtual resources. The server 1106 can be any suitable computer or collection of computers executing software capable of managing, distributing, and/or validating representations of credentials and keys for users and groups of users via a network as described herein...), the recipient device configured to retrieve the token from the relay server with the [representation] (FIG. 11 and col. 15, lines 31-33 - The client device 1102 then optionally sends a communication 1114 to a client device 1104 of the recipient to provide the client device 1104 with the representation of the key and col. 15, lines 52-54 - The recipient may send an access request 1116 related to the key from the client device 1104 using the client device 1104 and col. 15, lines 64-66 - Upon receiving the request 1116, the server 1106 can determine if the representation of the key used for generating the request is valid);
receive a uniform resource locator (URL) for retrieving the token from the relay server (FIG. 11 and col. 14, lines 39-64 - In operation, the server 1106 manages and/or stores one or more credentials, associates users, groups of users, and keys with appropriate credentials, and provides the credentials and keys to users' client devices to allow the users to access various physical and virtual resources. The server 1106 can be any suitable computer or collection of computers executing software capable of managing, distributing, and/or validating representations of credentials and keys for users and groups of users via a network as described herein... and col. 15, lines 16-30 - The server 1106 can then provide a notification 1112 including a representation of the key (e.g., a QR code, a sonic code, or an alphanumeric code) to the client device 1102 requesting the code. In some implementations, the notification 1112 may include information that allows the client device 1102 to generate the representation of the key locally. For example, the notification 1112 can include an URL for accessing the corresponding key, and the client device 1102 generates a representation (e.g., a QR code) that encodes the URL. In some implementations, the notification 1112 can include a reference code (e.g., an alphanumeric code) that is generated at the server 1106 and identifies the key. The client device can be configured to generate the representation (e.g., a QR code that encodes the reference code) based on the reference code.
provide, via a communication application executed by the origination device, the uniform resource locator to the recipient device for retrieval of the token (FIG. 11 and col. 14, lines 39-64 - In operation, the server 1106 manages and/or stores one or more credentials, associates users, groups of users, and keys with appropriate credentials, and provides the credentials and keys to users' client devices to allow the users to access various physical and virtual resources. The server 1106 can be any suitable computer or collection of computers executing software capable of managing, distributing, and/or validating representations of credentials and keys for users and groups of users via a network as described herein... and col. 15, lines 16-30 - The server 1106 can then provide a notification 1112 including a representation of the key (e.g., a QR code, a sonic code, or an alphanumeric code) to the client device 1102 requesting the code. In some implementations, the notification 1112 may include information that allows the client device 1102 to generate the representation of the key locally. For example, the notification 1112 can include an URL for accessing the corresponding key, and the client device 1102 generates a representation (e.g., a QR code) that encodes the URL. In some implementations, the notification 1112 can include a reference code (e.g., an alphanumeric code) that is generated at the server 1106 and identifies the key. The client device can be configured to generate the representation (e.g., a QR code that encodes the reference code) based on the reference code and col. 15, lines 31-33 - The client device 1102 then optionally sends a communication 1114 to a client device 1104 of the recipient to provide the client device 1104 with the representation of the key and col. 15, lines 52-54 - The recipient may send an access request 1116 related to the key from the client device 1104 using the client device 1104 and col. 15, lines 64-66 - Upon receiving the request 1116, the server 1106 can determine if the representation of the key used for generating the request is valid).
Gehret fails to explicitly disclose:
identify one or more limitations, comprising an indication of the access credential that define one or more time periods that the access credential is useable by the recipient device;
provide an indication of the one or more limitations to [a] credential manager;
...wherein the token is generated based at leas tin part of the one or more limitations;
generate a password for protection of the token
provide the token and the password to a ... server for storage, the recipient device configured to retrieve the token from the ... server with the password.
However, in an analogous art, Kwok teaches:
identify one or more limitations, comprising an indication of the access credential that define one or more time periods that the access credential is useable by the recipient device ([0046] and [0047] - In some embodiments, the token management engine 115 may utilize the travel booking-related details and the data from the activity records 10 to create token bindings that bind the offline limited-use token 11 to certain types of activities, locations, times, entities, and other activity attributes and [0053] - The offline limited-use token 11 may then remain active for a duration until after a time period following the departure time of the flight of the travel itinerary 120. For example, the offline limited-use token 11 can be deactivated upon a duration of the booked flight after the departure time elapses, or after a number of days associated with the duration of the travel itinerary 120);
provide an indication of the one or more limitations to [a] credential manager ([0047] - In some embodiments, the token management engine 115 may utilize the travel booking-related details and the data from the activity records 10 to create token bindings that bind the offline limited-use token 11 to certain types of activities, locations, times, entities, and other activity attributes); [and]
[obtain a token corresponding to the access credential from [a] credential manager], wherein the token is generated based at least in part of the one or more limitations ([0046] - In some embodiments, based on the travel booking-related details recorded in the itinerary record, the token management engine 115 may generate an offline limited-use token 11 for the user account. In some embodiments, the offline token limited-use 11 may include an account identifier and/or account activity authorization code that links the offline limited-use token 11 to the user account to authenticate account activities using the offline limited-use token 11.)
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Kwok to the token of Gehret to include identify one or more limitations, comprising an indication of the access credential that define one or more time periods that the access credential is useable by the recipient device; provide an indication of the one or more limitations to [a] credential manager; [and] [obtain a token corresponding to the access credential from [a] credential manager], wherein the token is generated based at least in part of the one or more limitations
One would have been motivated to combine the teachings of Kwok to Gehret to do so as it provides / allows improved generation of authentication tokens through automated and dynamic means such that the tokens have parameters that are automatically set to authentic user activities for limited uses during limited times (Kwok, [0013]).
However, in an analogous art, Weiss teaches:
generate a password for protection of the “secret data” ([0055] - The system can also provide enhance security for encrypted data by the use of encryption key updates that are based on user group activity. Embodiments disclosed herein utilize a vault key and a combination of other security keys to control access to secret data shared by members of a group and [0058] - The server 120 can manage one or more services for storing secret data received from the client devices 110. The secret data, which can include encrypted secret data 101′, encrypted secret keys 102′, and encrypted vault keys 104′, can be stored in association with a vault 109. The vault 109 can be associated with a user group 111 having a group identifier 112 and a listing of user identities 113 for each member of the group 111 and [0061] - To store secret data within a vault 109, each group member can encrypt secret data 101 using a secret key 102 on a client device 110 to generate encrypted data 101′. In some configurations, the secret key 102 can include a symmetric key. Each group member can also utilize a vault key 104 to encrypt the secret key 102 to generate an encrypted secret key 102′. In addition, each group member can also encrypt the vault key 104 using a public key from a public-private key pair to generate an encrypted vault key 104′. Each user can then communicate their respective encrypted data 101′, encrypted secret key 102′, and encrypted vault key 104′ to the server 120 for storage in the vault 109. When the user desires to retrieve the stored data, each user can obtain the vault key 104 by the use of their corresponding private key of the public-private key pair to decrypt the encrypted vault key 104′. Then each user can utilize the vault key 104 to access the secret key 102 and ultimately access the secret data 101.) As reasonably constructed a vault key is a form of a password.
provide the “secret data” and the password to a ... server for storage, the recipient device configured to retrieve the “secret data” from the ... server with the password ([0058] - The server 120 can manage one or more services for storing secret data received from the client devices 110. The secret data, which can include encrypted secret data 101′, encrypted secret keys 102′, and encrypted vault keys 104′, can be stored in association with a vault 109. The vault 109 can be associated with a user group 111 having a group identifier 112 and a listing of user identities 113 for each member of the group 111 and [0061] - To store secret data within a vault 109, each group member can encrypt secret data 101 using a secret key 102 on a client device 110 to generate encrypted data 101′. In some configurations, the secret key 102 can include a symmetric key. Each group member can also utilize a vault key 104 to encrypt the secret key 102 to generate an encrypted secret key 102′. In addition, each group member can also encrypt the vault key 104 using a public key from a public-private key pair to generate an encrypted vault key 104′. Each user can then communicate their respective encrypted data 101′, encrypted secret key 102′, and encrypted vault key 104′ to the server 120 for storage in the vault 109. When the user desires to retrieve the stored data, each user can obtain the vault key 104 by the use of their corresponding private key of the public-private key pair to decrypt the encrypted vault key 104′. Then each user can utilize the vault key 104 to access the secret key 102 and ultimately access the secret data 101.) As reasonably constructed a vault key is a form of a password.
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Weiss to the token of Gehret to include generate a password for protection of the “secret data”; provide the “secret data” and the password to a ... server for storage, the recipient device configured to retrieve the “secret data” from the ... server with the password.
One would have been motivated to combine the teachings of Weiss to Gehret to do so as it provides / allows improved management of access rights for dynamic groups of users sharing secret data ([0004, Weiss).
Regarding Claim 7;
Gehret and Kwok and Weiss disclose the media to claim 1.
Gehret further discloses wherein the recipient device operates a different platform that the origination device (FIG. 11 and col. 16, lines 38-50 - The client devices 1102, 1104 may be any type of computing device, including but not limited to a mobile phone, smart phone, personal digital assistant (PDA), music player, e-book reader, tablet computer, laptop or desktop computer, or other stationary or portable device, that includes one or more processors and non-transitory computer readable storage media. The application that is installed on the client devices can be written in any suitable programming language such as, for example, Objective-C, C++, Java, etc.).
Regarding Claim 15;
Gehret and Kwok discloses the device to Claim 9.
Gehret discloses concepts ...provide to the recipient device out of band out of band (FIG. 11 – 1114 and col. 15, lines 31-51).
Gehret in view of Kwok fail to explicitly disclose wherein the processing circuitry is further configured to: generate a password for access of the token stored on the relay server; and provide the password....
However, in an analogous, Weiss teaches wherein the processing circuitry is further configured to: generate a password for access of the token stored on the relay server and provide the password.... ([0058] - The server 120 can manage one or more services for storing secret data received from the client devices 110. The secret data, which can include encrypted secret data 101′, encrypted secret keys 102′, and encrypted vault keys 104′, can be stored in association with a vault 109. The vault 109 can be associated with a user group 111 having a group identifier 112 and a listing of user identities 113 for each member of the group 111 and [0061] - To store secret data within a vault 109, each group member can encrypt secret data 101 using a secret key 102 on a client device 110 to generate encrypted data 101′. In some configurations, the secret key 102 can include a symmetric key. Each group member can also utilize a vault key 104 to encrypt the secret key 102 to generate an encrypted secret key 102′. In addition, each group member can also encrypt the vault key 104 using a public key from a public-private key pair to generate an encrypted vault key 104′. Each user can then communicate their respective encrypted data 101′, encrypted secret key 102′, and encrypted vault key 104′ to the server 120 for storage in the vault 109. When the user desires to retrieve the stored data, each user can obtain the vault key 104 by the use of their corresponding private key of the public-private key pair to decrypt the encrypted vault key 104′. Then each user can utilize the vault key 104 to access the secret key 102 and ultimately access the secret data 101.) As reasonably constructed a vault key is a form of a password.
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Weiss to the token of Gehret in view of Kwok to include wherein the processing circuitry is further configured to: generate a password for access of the token stored on the relay server and provide the password....
One would have been motivated to combine the teachings of Weiss to Gehret in view of Kwok to do so as it provides / allows improved management of access rights for dynamic groups of users sharing secret data ([0004, Weiss).
Regarding Claim(s) 25; claim(s) 25 is/are directed to a/an method associated with the device claimed in claim(s) 25. Claim(s) 25 is/are similar in scope to claim(s) 15, and is/are therefore rejected under similar rationale.
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gehret et al. (US 9,608,970 B1) in view of Kwok et al. (US 2022/0141215 A1) and Weiss et al. (US 2021/0165898 A1) and further in view of Everton et al. (US 10,904,186 B1).
Regarding Claim 3;
Gehret and Kwok and Weiss disclose the media to claim 1.
Gehret further discloses further cause the origination device to: provide ... the relay server with the token and the [representation] (col. 10, lines 29-42 - In some implementations, when a user activates the control 604, the user interface 610 shown in FIG. 6B can be provided, to allow the user to share the key with another user. In some implementations, activation of the control 604 can initiate transmission of a request to a remote server (e.g., a server associated with the credential management system) to provide one or more shareable representations of the key. In some implementations, the shareable representations may also be generated locally at the client device of the user initiating the key-sharing. In such a case, the client device generating the representation of the key may transmit information about the generated representation to a remote entity (e.g., the server associated with the credential management system) that validates a use of the key and col. 14, lines 39-64 - In operation, the server 1106 manages and/or stores one or more credentials, associates users, groups of users, and keys with appropriate credentials, and provides the credentials and keys to users' client devices to allow the users to access various physical and virtual resources. The server 1106 can be any suitable computer or collection of computers executing software capable of managing, distributing, and/or validating representations of credentials and keys for users and groups of users via a network as described herein...), the recipient device configured to retrieve the token from the relay server with the [representation] (FIG. 11 and col. 15, lines 31-33 - The client device 1102 then optionally sends a communication 1114 to a client device 1104 of the recipient to provide the client device 1104 with the representation of the key and col. 15, lines 52-54 - The recipient may send an access request 1116 related to the key from the client device 1104 using the client device 1104 and col. 15, lines 64-66 - Upon receiving the request 1116, the server 1106 can determine if the representation of the key used for generating the request is valid);
Weiss further teaches provide ...the ... server with “secret data” and the password ([0058] - The server 120 can manage one or more services for storing secret data received from the client devices 110. The secret data, which can include encrypted secret data 101′, encrypted secret keys 102′, and encrypted vault keys 104′, can be stored in association with a vault 109. The vault 109 can be associated with a user group 111 having a group identifier 112 and a listing of user identities 113 for each member of the group 111 and [0061] - To store secret data within a vault 109, each group member can encrypt secret data 101 using a secret key 102 on a client device 110 to generate encrypted data 101′. In some configurations, the secret key 102 can include a symmetric key. Each group member can also utilize a vault key 104 to encrypt the secret key 102 to generate an encrypted secret key 102′. In addition, each group member can also encrypt the vault key 104 using a public key from a public-private key pair to generate an encrypted vault key 104′. Each user can then communicate their respective encrypted data 101′, encrypted secret key 102′, and encrypted vault key 104′ to the server 120 for storage in the vault 109. When the user desires to retrieve the stored data, each user can obtain the vault key 104 by the use of their corresponding private key of the public-private key pair to decrypt the encrypted vault key 104′. Then each user can utilize the vault key 104 to access the secret key 102 and ultimately access the secret data 101.) As reasonably constructed a vault key is a form of a password.
Similar rationale and motivation is noted for the combination of Weiss to Gehret and Kwok and Weiss, as per claim 1, above.
Gehret in view of Kwok and Weiss fail to explicitly disclose wherein the instructions, when executed by the one or more processors, further cause [a] device to: generate a mailbox identifier for the token; and ... the mailbox identifier to [a] server... , the [[relay]] server configured to store a token associated with the mailbox identifier and identify the token for retrieval by the recipient device based at least in part on the mailbox identifier.
However, in an analogous art, Everton teaches wherein the instructions, when executed by the one or more processors, further cause [a] device to: generate a mailbox identifier for the token (FIG. 2B and col. 3, lines 36-56 - The mail_data table 252 stores an identifier of a label created on the mailbox 116... or example, a record in the credentials table for mailbox 116 includes: an identifier of the mailbox 116 on the email host 108; a token field that stores an OAuth 2.0 token for that grants email processor 102 access to mailbox 116; and a timestamp field that indicates when the OAuth 2.0 token expires); and ... the mailbox identifier [stored on a] server... (FIG. 2B and col. 3, lines 36-56 - The mail_data table 252 stores an identifier of a label created on the mailbox 116... or example, a record in the credentials table for mailbox 116 includes: an identifier of the mailbox 116 on the email host 108; a token field that stores an OAuth 2.0 token for that grants email processor 102 access to mailbox 116; and a timestamp field that indicates when the OAuth 2.0 token expires), the [[relay]] server configured to store a token associated with the mailbox identifier and identify the token for retrieval by the recipient device based at least in part on the mailbox identifier (FIG. 2B and col. 3, lines 36-56 - The mail_data table 252 stores an identifier of a label created on the mailbox 116... or example, a record in the credentials table for mailbox 116 includes: an identifier of the mailbox 116 on the email host 108; a token field that stores an OAuth 2.0 token for that grants email processor 102 access to mailbox 116; and a timestamp field that indicates when the OAuth 2.0 token expires),
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Everton to the token/server of Gehret in view of Kwok and Weiss to include wherein the instructions, when executed by the one or more processors, further cause [a] device to: generate a mailbox identifier for the token; and provide the mailbox identifier to [a] server... , the [[relay]] server configured to store a token associated with the mailbox identifier and identify the token for retrieval by the recipient device based at least in part on the mailbox identifier.
One would have been motivated to combine the teachings of Everton to Gehret in view of Kwok and Weiss to do so as it provides / allows improve the privacy and security of email (Everton, col. 1, lines 5-11).
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gehret et al. (US 9,608,970 B1) in view of Kwok et al. (US 2022/0141215 A1) and Weiss et al. (US 2021/0165898 A1) and further in view of Sharifi Mehr (US 9,973,481 B1).
Regarding Claim 4;
Gehret and Kwok and Weiss disclose the media to claim 1.
Gehret further discloses concepts of the origination device and token and relay server (FIG. 11 and col. 9, lines 40-47 - FIG. 3 shows an illustration of an example of a user interface 300 that enables a user to manage one or more keys associated with a credential).
Gehret in view of Kwok and Weiss fail to explicitly disclose wherein the instructions, when executed by the one or more processors, further cause [a] device to encrypt the [data], wherein the [data] provided to [a] server is the encrypted [data], and wherein the ... server is unable to decode the encrypted [data].
However, in an analogous, Sharifi Mehr teaches wherein the instructions, when executed by the one or more processors, further cause [a] device to encrypt the token, wherein the token provided to [a] server is the encrypted token, and wherein the ... server is unable to decode the encrypted token (col. 3, lines 58-col. 4, lines 3 - In certain implementations where the encryption and decryption of data is performed by the client (client-side encryption), the client exchanges encrypted data with the storage server. Before sending data to the storage server, the client encrypts the data with a DEK, and sends the DEK to a data encryption key server, receiving a DEKR in response. The client sends the encrypted data and the DEKR to the storage server. The storage server stores the data records without decrypting or further encrypting the information in the record. When the client requests the data record, the data record is returned to the client without decrypting the data, and the decrypting operations are performed by the client. In some implementations, the storage server is unable to decrypt the data and/or resolve the DEKR to a DEK.).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Sharifi Mehr to the origination device and token and relay server of Gehret in view of Kwok and Weiss to include wherein the instructions, when executed by the one or more processors, further cause [a] device to encrypt the token, wherein the token provided to [a] server is the encrypted token, and wherein the ... server is unable to decode the encrypted token.
One would have been motivated to combine the teachings of Sharifi Mehr to Gehret in view of Kwok and Weiss to do so as it provides / allows to secure sensitive data by encrypting the data with an envelope-based encryption scheme (Sharifi Mehr, col. 3, lines 1-3).
Claim(s) 5-6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gehret et al. (US 9,608,970 B1) in view of Kwok et al. (US 2022/0141215 A1) and Weiss et al. (US 2021/0165898 A1) and further in view of Corella et al. (US 2015/0113283 A1).
Regarding Claim 5;
Gehret and Kwok and Weiss disclose the media to claim 1.
Gehret further discloses wherein the instructions, when executed by the one or more processors, further cause the origination device to generate a [representation] and provide the [representation] to the recipient device, the recipient device configured to use the [representation] for provisioning of the access credential (FIG. 11 and col. 15, lines 64-col. 16, lines 20).
Gehret in view of Kwok and Weiss fail to explicitly disclose detect a key provided by [a] device; generate a signature based at least in part on the key; and provide the signature to the.. device, the ... device configured to use the signature for provisioning of the access credential.
However, in an analogous art, Corella teaches detect a key provided by [a] device (FIG. 17 and [0044] - An "uncertified key pair" is a key pair whose public key component has not been certified by a certificate authority, and therefore is not included in a certificate signed by certificate authority and [0086] - At 1710 credential activation program 125 initiates a TLS connection to key storage service 135. During the initial handshake of the connection, service 135 authenticates to program 125 by presenting a TLS server certificate and demonstrating knowledge of the corresponding private key. The server certificate is issued by a certificate authority (CA) and backed by a certificate chain that ends with the public key of a root CA known to the program) As constructed certificate backed by a CA represents a public key component that has been backed by a CA (i.e., from of a key provided by a device); and generate a signature based at least in part on the key (FIG. 17 and (FIG. 17 and [0044] and [0086] - At 1710 credential activation program 125 initiates a TLS connection to key storage service 135. During the initial handshake of the connection, service 135 authenticates to program 125 by presenting a TLS server certificate and demonstrating knowledge of the corresponding private key. The server certificate is issued by a certificate authority (CA) and backed by a certificate chain that ends with the public key of a root CA known to the program and [0087] - The proof of possession comprises device record handle 165, the public key component of key pair 610, and a signature computed with the private key component of key pair 610 on the master key of the TLS connection concatenated with the TLS server certificate. Since service 135 authenticated during the handshake with a TLS server certificate, and the ciphersuite used by the connection provides data authentication, the proof of possession is sent to service 135 with destination authentication. After 1720 the process continues at 1730. ); and provide the signature to the.. device, the ... device configured to use the signature for provisioning of the access credential ((FIG. 17 and [0088] At 1730, service 135 verifies the signature using the public key. If the verification fails, the process continues at 1732. If the verification succeeds, the process continues at 1734 and [0094] At 1770, service 135 sends credential activation key 130 found in device record 155 to program 125.).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Corella to the provisioning of Gehret in view of Kwok and Weiss to include detect a key provided by [a] device; generate a signature based at least in part on the key; and provide the signature to the.. device, the ... device configured to use the signature for provisioning of the access credential.
One would have been motivated to combine the teachings of Corella to Gehret in view of Kwok and Weiss to do so as it provides / allows to protect credentials stored in a computing device against being used by an unauthorized user who physically captures the device (Corella, [0012]).
Regarding Claim 6;
Gehret and Kwok and Weiss and Corella disclose the media to claim 5.
Gehret further discloses the recipient device (FIG. 11)
Corella further teaches wherein the key comprises a public key of an asymmetric key pair generated... , wherein the signature covers the public key ([0044] and Claim 1 - the device sending the bearer tokens, the public key and a signature computed with the private key to a key storage service with destination authentication). As constructed a signature computed with the private key “covers” the public key as its an asymmetric key pair (i.e., public key cryptosystem).
Similar rationale and motivation is noted for the combination of Corella to Kwok and Gehret and Weiss and Corella, ser per claim 5, above.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gehret et al. (US 9,608,970 B1) in view of Kwok et al. (US 2022/0141215 A1) and Weiss et al. (US 2021/0165898 A1) and further in view of M'Raihi et al. (US 2013/0298211 A1).
Regarding Claim 8;
Gehret and Kwok and Weiss disclose the media to claim 1.
Gehret in view of Kwok and Weiss fail to explicitly disclose wherein the access credential is an unclonable access credential.
However, in an analogous art, M'Raihi teaches wherein the access credential is an unclonable access credential ([0048] - In accordance with one aspect of the present invention, if there is reliance upon the PUFs (Physically Unclonable Functions) technology to generate an authentication credential).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of M'Raihi to the access credential of Gehret in view of Kwok and Weiss to include wherein the access credential is an unclonable access credential.
One would have been motivated to combine the teachings of M'Raihi to Gehret in view of Kwok and Weiss to do so as it provides / allows access to a secure network through verification via PUFs technology (M'Raihi, [0002] and [0048]).
Claim(s) 9, 10, 21, 22 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Gehret et al. (US 9,608,970 B1) in view of Kwok et al. (US 2022/0141215 A1).
Regarding Claim 9
Gehret discloses an origination device, comprising: (FIG. 11 – Requester (1102)),
memory configured to store an access credential for access to an entity, the access credential to provide access to a secured entity (FIG. 1 and FIG. 3 and FIG. 4 and FIG. 11 – Requester (1102)) and col. 8, lines 32-43 - FIG. 1 shows a sample user interface 100 that enables a user to select from among various credentials of the user. The interface 100 can be provided as a part of a credential management application that allows a user to create a user-account and manage credentials that may be associated with the user account. In some implementations, the various credentials may be issued by different organizations. In particular, the user interface 100 includes an example of a user's wallet (identified with a “User Wallet” caption 102) that provides the user with access to numerous different credentials associated with the user and col. 9, lines 40-47 - FIG. 3 shows an illustration of an example of a user interface 300 that enables a user to manage one or more keys associated with a credential)
processing circuitry coupled to the memory (FIG. 1 and FIG. 3 and FIG. 4 and FIG. 11 – Requester (1102)), the processing circuitry configured to:
display an indication that the access credential can be shared with a recipient device (FIG. 3 and FIG. 4 and FIG. 11 and col. 9, lines 40-47 - FIG. 3 shows an illustration of an example of a user interface 300 that enables a user to manage one or more keys associated with a credential and col. 10, lines 10-28 - Referring again to FIG. 4, in some implementations, the user interface 400 can also include a control 406 that enables the user to share the selected “key” with another user by selecting the icon 406. Selecting the icon 406 can launch another interface that allows the user to share the selected “key” with one or more other users and col. 10, lines 29-35 - In some implementations, when a user activates the control 604, the user interface 610 shown in FIG. 6B can be provided, to allow the user to share the key with another user. In some implementations, activation of the control 604 can initiate transmission of a request to a remote server (e.g., a server associated with the credential management system) to provide one or more shareable representations of the key.);
detect a user selection of the access credential to be shared with the recipient device (FIG. 3 and FIG. 4 and FIG. 11 and col. 9, lines 40-47 - FIG. 3 shows an illustration of an example of a user interface 300 that enables a user to manage one or more keys associated with a credential) and col. 10, lines 10-28 - Referring again to FIG. 4, in some implementations, the user interface 400 can also include a control 406 that enables the user to share the selected “key” with another user by selecting the icon 406. Selecting the icon 406 can launch another interface that allows the user to share the selected “key” with one or more other users and col. 14, lines 39-64 - In operation, the server 1106 manages and/or stores one or more credentials, associates users, groups of users, and keys with appropriate credentials, and provides the credentials and keys to users' client devices to allow the users to access various physical and virtual resources. The server 1106 can be any suitable computer or collection of computers executing software capable of managing, distributing, and/or validating representations of credentials and keys for users and groups of users via a network as described herein...);
obtain a token corresponding to the access credential (col. 10, lines 29-42 - In some implementations, when a user activates the control 604, the user interface 610 shown in FIG. 6B can be provided, to allow the user to share the key with another user. In some implementations, activation of the control 604 can initiate transmission of a request to a remote server (e.g., a server associated with the credential management system) to provide one or more shareable representations of the key. In some implementations, the shareable representations may also be generated locally at the client device of the user initiating the key-sharing. In such a case, the client device generating the representation of the key may transmit information about the generated representation to a remote entity (e.g., the server associated with the credential management system) that validates a use of the key and col. 14, lines 39-64 - In operation, the server 1106 manages and/or stores one or more credentials, associates users, groups of users, and keys with appropriate credentials, and provides the credentials and keys to users' client devices to allow the users to access various physical and virtual resources. The server 1106 can be any suitable computer or collection of computers executing software capable of managing, distributing, and/or validating representations of credentials and keys for users and groups of users via a network as described herein...);
provide the token to a relay server for storage (col. 10, lines 29-42 - In some implementations, when a user activates the control 604, the user interface 610 shown in FIG. 6B can be provided, to allow the user to share the key with another user. In some implementations, activation of the control 604 can initiate transmission of a request to a remote server (e.g., a server associated with the credential management system) to provide one or more shareable representations of the key. In some implementations, the shareable representations may also be generated locally at the client device of the user initiating the key-sharing. In such a case, the client device generating the representation of the key may transmit information about the generated representation to a remote entity (e.g., the server associated with the credential management system) that validates a use of the key and col. 14, lines 39-64 - In operation, the server 1106 manages and/or stores one or more credentials, associates users, groups of users, and keys with appropriate credentials, and provides the credentials and keys to users' client devices to allow the users to access various physical and virtual resources. The server 1106 can be any suitable computer or collection of computers executing software capable of managing, distributing, and/or validating representations of credentials and keys for users and groups of users via a network as described herein...), the recipient device configured to retrieve the token from the relay server for provision of the access credential (FIG. 11 and col. 15, lines 31-33 - The client device 1102 then optionally sends a communication 1114 to a client device 1104 of the recipient to provide the client device 1104 with the representation of the key and col. 15, lines 52-54 - The recipient may send an access request 1116 related to the key from the client device 1104 using the client device 1104 and col. 15, lines 64-66 - Upon receiving the request 1116, the server 1106 can determine if the representation of the key used for generating the request is valid);
receive a uniform resource locator (URL) for retrieving the token from the relay server (FIG. 11 and col. 14, lines 39-64 - In operation, the server 1106 manages and/or stores one or more credentials, associates users, groups of users, and keys with appropriate credentials, and provides the credentials and keys to users' client devices to allow the users to access various physical and virtual resources. The server 1106 can be any suitable computer or collection of computers executing software capable of managing, distributing, and/or validating representations of credentials and keys for users and groups of users via a network as described herein... and col. 15, lines 16-30 - The server 1106 can then provide a notification 1112 including a representation of the key (e.g., a QR code, a sonic code, or an alphanumeric code) to the client device 1102 requesting the code. In some implementations, the notification 1112 may include information that allows the client device 1102 to generate the representation of the key locally. For example, the notification 1112 can include an URL for accessing the corresponding key, and the client device 1102 generates a representation (e.g., a QR code) that encodes the URL. In some implementations, the notification 1112 can include a reference code (e.g., an alphanumeric code) that is generated at the server 1106 and identifies the key. The client device can be configured to generate the representation (e.g., a QR code that encodes the reference code) based on the reference code); and
provide, via a communication application executed by the origination device, the uniform resource locator to the recipient device for retrieval of the token (FIG. 11 and col. 14, lines 39-64 - In operation, the server 1106 manages and/or stores one or more credentials, associates users, groups of users, and keys with appropriate credentials, and provides the credentials and keys to users' client devices to allow the users to access various physical and virtual resources. The server 1106 can be any suitable computer or collection of computers executing software capable of managing, distributing, and/or validating representations of credentials and keys for users and groups of users via a network as described herein... and col. 15, lines 16-30 - The server 1106 can then provide a notification 1112 including a representation of the key (e.g., a QR code, a sonic code, or an alphanumeric code) to the client device 1102 requesting the code. In some implementations, the notification 1112 may include information that allows the client device 1102 to generate the representation of the key locally. For example, the notification 1112 can include an URL for accessing the corresponding key, and the client device 1102 generates a representation (e.g., a QR code) that encodes the URL. In some implementations, the notification 1112 can include a reference code (e.g., an alphanumeric code) that is generated at the server 1106 and identifies the key. The client device can be configured to generate the representation (e.g., a QR code that encodes the reference code) based on the reference code and col. 15, lines 31-33 - The client