Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/12/2026 has been entered.
Response to Amendment
Applicant arguments filed 02/12/2026, with respect to objections to the claims have been fully considered, and the objections have been withdrawn in view of the amendments.
Response to Arguments
Applicant’s arguments filed 02/12/2026, with respect to the rejections of independent claims 1, 15, and 18 and their corresponding dependent claims under 35 USC 103 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, new grounds of rejection are made in view of the previously applied reference from Guo et al. (US 20090300744 A1), hereinafter Guo, in combination with newly applied references from Chen et al. (US 8464058 B1), hereinafter Chen, and Netwoven (Netwoven, “Azure AD - Break Glass Account for Microsoft 365,” YouTube (Mar. 28, 2021), https://www.youtube.com/watch?v=Osi1htxuFOw), hereinafter Netwoven. Examiner respectfully submits that the newly applied combination is sufficient to render obvious at least the independent claims as amended. Specifically, the combination of Guo, Chen, and Netwoven teaches the amended limitations “in response to a request to create an Account of Last Resort (ALR), query a user for a logon credential to be used with the created ALR”; “based on the logon credential, generate a credential-based encryption key”; “based on data specific to the IHS, generate an IHS-specific encryption key”; “wherein authenticating for logon access to the ALR includes: receiving user-entered credentials in response to verifying that the user-entered credentials match the logon credential, prompting the user for the signed digital certificate”; and “and in response to verifying the user providing the copy of the signed digital certificate, granting access to the ALR”.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action.
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 15, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Guo et al. (US 20090300744 A1), hereinafter Guo, in view of Chen et al. (US 8464058 B1), hereinafter Chen, and Netwoven (Netwoven, “Azure AD - Break Glass Account for Microsoft 365,” YouTube (Mar. 28, 2021), https://www.youtube.com/watch?v=Osi1htxuFOw), hereinafter Netwoven.
Regarding Claim 1:
Guo teaches an Information Handling System (IHS), comprising: a processor; and a memory coupled to the processor, the memory having program instructions stored thereon that, upon execution, cause the IHS to (Guo – Paragraph [0054]: the computer 20 includes a processing unit 21, a system memory 22, and a system bus 23 that operatively couples various system components including the system memory to the processing unit 21; and Paragraph [0056]: The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computer 20): … a request to create an Account … a logon credential to be used (Guo – Paragraph [0027]: The user device collects and sends a username/password and device ID/password (and potentially, a user-friendly device name) to the account authority service in a transmission operation 204 in association with a request to create an account); wherein authenticating for logon access [to the ALR] includes: receiving user-entered credentials (Guo – Paragraph [0034]: the user requests access to the secure server in a request operation 302 (e.g., by navigating a browser to a web page served by the secure server). The secure server device detects that the user has not yet been authenticated ... and therefore redirects the user to the account authority service for authentication in a redirection operation 304; and Paragraph [0035]: A prompting operation 308 at the account authority service prompts the user for credentials. The user device receives the prompt at a receiving operation 310 and submits credentials in a sending operation 312. The user may submit his or her user credentials (e.g., username and password)); in response to verifying that the user-entered credentials match the logon credential, prompting the user for the signed digital certificate (Guo – Figure 3: illustration of a process for authentication of a user to access a secure server; and Paragraph [0036]: when the account authority service receives the credentials from the user device, it authenticates them and, if the credentials satisfy the secure server's security requirements (as determined in a decision operation 314), the account authority service sends a security token to the user device in an operation 320; and Paragraph [0037]: If the user-device-supplied credentials do not satisfy the security requirements of the secure server, the account authority service 316 may prompt the user device for addition credentials. For example, if the secure server requires a two factor authentication, such as both user and device credentials, the account authority server may require the user to authenticate via a trusted device; and Paragraph [0035]: The user may submit his or her user credentials (e.g., username and password), which is typical. In an alternative scenario, the user device may also submit a device certificate (or device ID and device password), thereby providing two factors for authentication); and in response to verifying the user providing the copy of the signed digital certificate, granting access [to the ALR] (Guo – Figure 3: illustration of a process for authentication of a user to access a secure server; and Paragraph [0039]: The user device receives the security token in receiving operation 322 and forwards it to the secure server in a sending operation 324. In a granting operation 326, the secure server interrogates the security token to determine a level of privilege to authorize for the user/device, based on the authentication performed by the account authority service. In one implementation, the secure server interrogates the security token to determine whether both user credentials and device credentials were included in the authentication with the account authority service. If so, the secure server can allow a higher level of privilege to the user via the user device).
Guo does not expressly teach based on the [logon] credential, generate a credential-based encryption key; generate a digital certificate using the credential-based encryption key; based on data specific to the IHS, generate an IHS-specific encryption key; sign the digital certificate using the IHS-specific encryption key; and deliver a copy of the signed digital certificate to the user.
However, Chen teaches based on the [logon] credential, generate a credential-based encryption key (Chen – Figure 2: illustration of a registration phase in which a user establishes a relationship with a server for continued cryptographic authentication operations; and Col. 7, Line 47-53: the registration phase proceeds as follows: U sends pw to S (arrow 31). S uses pw and its master key ms.sub.S (d) to compute pk.sub.U (step 32) as: pk.sub.U=g.sup.1/(H.sup.1.sup.(pw).sup.d .sup.mod n) mod P); generate a digital certificate using the credential-based encryption key (Chen – Col. 7, Line 53-62: S also computes: k=H.sub.2(d.parallel.I.sub.U.parallel.pwText) cer.sub.U=cerGen(k, I.sub.U.parallel.pk.sub.U.parallel.pwText)); based on data specific to the IHS, generate an IHS-specific encryption key (Chen – Col. 9, Line 16-19: the server S also creates (in step 21) a secret/public key pair sk.sub.S and pk.sub.S respectively for signing/verification purposes; optionally, this key pair can be constituted by the RSA secret/public key pair (d, n)/(e, n); and Col. 7, Line 1-5: In step 21 the server S generates a prime e and two large primes, p and q; the server then computes n=pq and d=1/e mod (p-1)(q-1) after which it preferably deletes p and q but, if not, it keeps them secret; it will be appreciated that (d, n) and (e, n) constitute an RSA secret/public key pair); sign the digital certificate using the IHS-specific encryption key (Chen – Col. 7, Line 7-24: the server S publishes (makes available to domain users) domain public parameters comprising: … complementary signing and signature verification algorithms: Sig.sub.sk(m) and Ver.sub.vk(.sigma., m); and Col. 15, Line 59-65: in the described embodiments, the server S does not even need to store the tuple (pk.sub.U, I.sub.U) of each user as each such tuple is placed in a server-signed certificate cer.sub.U and given to the user to store, for return to the server when needed (at which time the server verifies the certificate and thus the integrity of the tuple, including the association of pk.sub.U and I.sub.U)); and deliver a copy of the signed digital certificate to the user (Chen – Col. 7, Line 61-62: S sends pk.sub.U, cer.sub.U to U (arrow 33) U stores pk.sub.U, cer.sub.U for later use (step 34)).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Guo, further incorporating Chen to arrive at the claimed invention. Chen teaches techniques for using a user’s password/credentials as a basis for generating an encryption key to be incorporated with a certificate for use in later authentication operations. Chen’s methods combine naturally with Guo’s account creation and use of multiple factors (credentials and device certificate) during account access, as Chen’s methods serve to enhance the security of the cryptographic relationship established between a user device and the server which provides a certificate to the device for later authentication. Thus, it would have been obvious to combine the teachings from Chen with those of Guo.
The combination of Guo and Chen does not expressly teach in response to a request to create an Account of Last Resort (ALR), query a user for a logon credential to be used with the created ALR.
However, Netwoven teaches in response to a request to create an Account of Last Resort (ALR) (Netwoven – 3:20-3:30: User intending to create a break glass account selects New User icon to initiate creation of a new account), query a user for a logon credential to be used with the created ALR (Netwoven – 3:30-4:30: In response to the New User selection, the user is presented with various input fields to be associated with the account including at least username and password).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Guo and Chen, further incorporating Netwoven to arrive at the claimed invention. One would be motivated to incorporate Netwoven’s account of last resort and the process of its creation in combination with Guo and Chen’s methods for fortified user authentication in association with account access. The combination of Guo’s account creation and establishment of account credentials for multi-factor authentication and Chen’s password-based cryptographic authentication and certificate generation techniques represent known methods to be applied to the additionally known account provisioning environment established by Netwoven. Applying these methods to the break-glass (or ALR) account would provide the account with stronger protection against unauthorized access. Thus, the combination would have been obvious.
Regarding Claim 2:
The combination of Guo, Chen, and Netwoven teaches the IHS of claim 1.
Guo further teaches wherein the logon credential comprises a password (Guo – Paragraph [0027]: The user device collects and sends a username/password and device ID/password (and potentially, a user-friendly device name) to the account authority service in a transmission operation 204 in association with a request to create an account).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 3:
The combination of Guo, Chen, and Netwoven teaches the IHS of claim 1.
Netwoven further teaches wherein the ALR is distinct from any other account uniquely provisioned for any of a plurality of users of the IHS (Netwoven – 3:20-3:30: When creating a New User as the breakglass/ALR account, other distinct individual user accounts are listed).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 15:
Claim 15 is a method claim with limitations corresponding to those of IHS Claim 1. Therefore, Claim 15 is rejected with the same combination and rationale as Claim 1.
Regarding Claim 18:
Claim 18 is a memory storage device claim with limitations corresponding to those of IHS Claim 1 and method Claim 15. Therefore, Claim 18 is rejected with the same combination and rationale as Claim 1 and Claim 15.
Guo further teaches the additional elements of a memory storage device having program instructions stored thereon that, upon execution by an Information Handling System (IHS), cause the IHS to (Guo – Paragraph [0054]: the computer 20 includes a processing unit 21, a system memory 22, and a system bus 23 that operatively couples various system components including the system memory to the processing unit 21; and Paragraph [0056]: The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computer 20).
Claim 5, 11, and 19 is rejected under 35 U.S.C. 103 as being unpatentable over Guo in view of Chen, Netwoven, and Hughes (US 20190074982 A1), hereinafter Hughes.
Regarding Claim 5:
The combination of Guo, Chen, and Netwoven teaches the IHS of claim 1.
The combination of Guo, Chen, and Netwoven does not expressly teach wherein to generate the digital certificate, the program instructions, upon execution, further cause the IHS to receive a certificate signing request (CSR) from the user.
However, Hughes teaches wherein to generate the digital certificate, the program instructions, upon execution, further cause the IHS to receive a certificate signing request (CSR) from the user (Hughes – Paragraph [0201]: Traditional web browser users have to manually click through a few web pages to fill in their user information, generate a user key pair, submit a CSR request, and retrieve their signed certificates).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Guo, Chen, and Netwoven, further incorporating Hughes to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Hughes’s teaching to initiate creation and signing of a certificate with a user CSR into Guo, Chen, and Netwoven’s combined system for enabling secure user access to an ALR account. This addition provides more direction for the system while giving the users more autonomy in the certificate generation and provision.
Regarding Claim 11:
The combination of Guo, Chen, and Netwoven teaches the IHS of claim 1.
The combination of Guo, Chen, and Netwoven does not expressly teach wherein authenticating for logon access to the ALR further includes proving possession of a private encryption key that is paired to a the credential-based encryption key used to generate the digital certificate.
However, Hughes teaches wherein authenticating for logon access to the ALR further includes proving possession of a private encryption key that is paired to a the credential-based encryption key used to generate the digital certificate (Hughes – Paragraph [0067]: IRP normally uses Strong Client Authentication (SCA) at login, for the user to authenticate to the server. With SCA, instead of a username and password, the user supplies their X.509 client digital certificate (possibly provided directly by a system administrator, or obtained online via IRP) to identify themselves. The actual proof of identity is based on possession of the private key associated with the public key in the certificate).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Guo, Chen, and Netwoven, further incorporating Hughes to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Hughes’s teaching to prove a user’s possession of a private key corresponding to the public key of the signed certificate into Guo, Chen, and Netwoven’s combined system for securely providing users access to a shared account. This combined functionality would further enhance the security of the system by adding another feature to authenticate a user attempting to access the shared account.
Regarding Claim 19:
The combination of Guo, Chen, and Netwoven teaches the memory storage device of claim 18.
The combination of Guo, Chen, and Netwoven does not expressly teach wherein the digital certificate comprises a the credential-based encryption key paired to another private encryption key that belongs to the user.
However, Hughes teaches wherein the digital certificate comprises a the credential-based encryption key paired to another private encryption key that belongs to the user (Hughes – Paragraph [0179]-[0182]: [0179] the user 401 initiates a transaction to request for a new certificate by entering her user information, and clicks an Enroll button to request for her digital certificate at a step 406. Thereafter, the web browser 403 does the following: [0180] Generate a public & private key pair for the user at a step 408; [0181] Create a CSR (Certificate Signing Request) from the user information & the generated public key at a step 410; [0182] Sign the CSR using the generated private key at a step 412).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Guo, Chen, and Netwoven, further incorporating Hughes to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Hughes’s teaching to implement certificates including a public key paired to a user private key into Guo, Chen, and Netwoven’s combined method for providing users access to a shared account. This combined functionality would enhance the user authentication capabilities associated with the certificate.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Guo in view of Chen, Netwoven, and Medvinsky et al. (US 11621842 B2), hereinafter Medvinsky.
Regarding Claim 6:
The combination of Guo, Chen, and Netwoven teaches the IHS of claim 1.
The combination of Guo, Chen, and Netwoven does not expressly teach wherein the program instructions, upon execution, further cause the IHS to deliver a private encryption key to the user along with the copy of the signed digital certificate.
However, Medvinsky teaches wherein the program instructions, upon execution, further cause the IHS to deliver a private encryption key to the user along with the copy of the signed digital certificate (Medvinsky – Col. 6, Lines 47-54: The ONCA 106 then signs the new device certificate 156 using the CA signing key 162 which is typically protected inside the HSM 160. In operation thirteen, the ONCA 106 returns the just issued client device certificate 156 along with the corresponding encrypted device private key 150 (which are copied unchanged from the database or repository 112) to the requesting client device 108 in the response message).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Guo, Chen, and Netwoven, further incorporating Medvinsky to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Medvinsky’s teaching to provide a user with a private key along with a signed digital certificate into Guo, Chen, and Netwoven’s combined method for providing users access to a shared account. This combined functionality would provide an additional means for verified users within the system to prove their authenticity in future operations.
Claims 7-10 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Guo in view of Chen, Netwoven, and Osorio Lozano et al. (US 20220108018 A1), hereinafter OL.
Regarding Claim 7:
The combination of Guo, Chen, and Netwoven teaches the IHS of claim 1.
The combination of Guo, Chen, and Netwoven does not expressly teach wherein the program instructions, upon execution, further cause the IHS to generate the IHS-specific encryption key based, at least in part, upon device identification information corresponding to hardware components of the IHS.
However, OL teaches wherein the program instructions, upon execution, further cause the IHS to generate the IHS-specific encryption key based, at least in part, upon device identification information corresponding to hardware components of the IHS (OL – Paragraph [0003]: This document discloses systems and methods for deriving identity and root keys for embedded systems … Executing the code of the ROM retrieves a silicon-specific key from the ROM, which can be used to verify a digest of code from a ROM extension image stored in non-volatile memory of the integrated circuit before execution of the ROM extension image … Additionally, a description of the code stored in non-volatile memory may be provided by software and used in combination with the root key and device identifier to generate a silicon-specific root key. The silicon-specific root key can be used to generate a silicon-specific (e.g., silicon creator or designer) identity key for signing certificates that endorse the authenticity of the silicon, the ROM, and/or the code from non-volatile memory).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Guo, Chen, and Netwoven, further incorporating OL to arrive at the conclusion of the claimed invention. One would be motivated to incorporate OL’s signing key generation based on a hierarchy beginning with a root key into Guo, Chen, and Netwoven’s combined system for providing users access to a shared account. This combined functionality would ensure that the private key used to sign the certificate was verifiably originated within the signing device (IHS).
Regarding Claim 8:
The combination of Guo, Chen, and Netwoven teaches the IHS of claim 1.
The combination of Guo, Chen, and Netwoven does not expressly teach wherein the program instructions, upon execution, further cause the IHS to generate the IHS-specific encryption key based, at least in part, upon another encryption key usable to perform verification of a hardware component of the IHS.
However, OL teaches wherein the program instructions, upon execution, further cause the IHS to generate the IHS-specific encryption key based, at least in part, upon another encryption key usable to perform verification of a hardware component of the IHS (OL – Paragraph [0003]: This document discloses systems and methods for deriving identity and root keys for embedded systems … Executing the code of the ROM retrieves a silicon-specific key from the ROM, which can be used to verify a digest of code from a ROM extension image stored in non-volatile memory of the integrated circuit before execution of the ROM extension image … Additionally, a description of the code stored in non-volatile memory may be provided by software and used in combination with the root key and device identifier to generate a silicon-specific root key. The silicon-specific root key can be used to generate a silicon-specific (e.g., silicon creator or designer) identity key for signing certificates that endorse the authenticity of the silicon, the ROM, and/or the code from non-volatile memory).
The motivation to combine the arts is the same as that of Claim 7.
Regarding Claim 9:
The combination of Guo, Chen, and Netwoven teaches the IHS of claim 1.
The combination of Guo, Chen, and Netwoven does not expressly teach wherein the program instructions, upon execution, further cause the IHS to generate the IHS-specific encryption key based, at least in part, upon another encryption key usable to perform verification of a firmware component of the IHS.
However, OL teaches wherein the program instructions, upon execution, further cause the IHS to generate the IHS-specific encryption key based, at least in part, upon another encryption key usable to perform verification of a firmware component of the IHS (OL – Paragraph [0003]: This document discloses systems and methods for deriving identity and root keys for embedded systems … Executing the code of the ROM retrieves a silicon-specific key from the ROM, which can be used to verify a digest of code from a ROM extension image stored in non-volatile memory of the integrated circuit before execution of the ROM extension image … Additionally, a description of the code stored in non-volatile memory may be provided by software and used in combination with the root key and device identifier to generate a silicon-specific root key. The silicon-specific root key can be used to generate a silicon-specific (e.g., silicon creator or designer) identity key for signing certificates that endorse the authenticity of the silicon, the ROM, and/or the code from non-volatile memory; Examiner’s Comment: firmware traditionally resides in ROM).
The motivation to combine the arts is the same as that of Claim 7.
Regarding Claim 10:
The combination of Guo, Chen, and Netwoven teaches the IHS of claim 1.
The combination of Guo, Chen, and Netwoven does not expressly teach wherein the program instructions, upon execution, further cause the IHS to generate the IHS-specific encryption key based, at least in part, upon another encryption key usable to perform verification of a software component of the IHS.
However, OL teaches wherein the program instructions, upon execution, further cause the IHS to generate the IHS-specific encryption key based, at least in part, upon another encryption key usable to perform verification of a software component of the IHS (OL – Paragraph [0003]: This document discloses systems and methods for deriving identity and root keys for embedded systems … Executing the code of the ROM retrieves a silicon-specific key from the ROM, which can be used to verify a digest of code from a ROM extension image stored in non-volatile memory of the integrated circuit before execution of the ROM extension image … Additionally, a description of the code stored in non-volatile memory may be provided by software and used in combination with the root key and device identifier to generate a silicon-specific root key. The silicon-specific root key can be used to generate a silicon-specific (e.g., silicon creator or designer) identity key for signing certificates that endorse the authenticity of the silicon, the ROM, and/or the code from non-volatile memory).
The motivation to combine the arts is the same as that of Claim 7.
Regarding Claim 16:
The combination of Guo, Chen, and Netwoven teaches the method of claim 15.
The combination of Guo, Chen, and Netwoven does not expressly teach further comprising: generating the IHS-specific encryption key based, at least in part, upon another encryption key usable to perform verification of a component of the IHS.
However, OL teaches further comprising: generating the IHS-specific encryption key based, at least in part, upon another encryption key usable to perform verification of a component of the IHS (OL – Paragraph [0003]: This document discloses systems and methods for deriving identity and root keys for embedded systems … Executing the code of the ROM retrieves a silicon-specific key from the ROM, which can be used to verify a digest of code from a ROM extension image stored in non-volatile memory of the integrated circuit before execution of the ROM extension image … Additionally, a description of the code stored in non-volatile memory may be provided by software and used in combination with the root key and device identifier to generate a silicon-specific root key. The silicon-specific root key can be used to generate a silicon-specific (e.g., silicon creator or designer) identity key for signing certificates that endorse the authenticity of the silicon, the ROM, and/or the code from non-volatile memory).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Guo, Chen, and Netwoven, further incorporating OL to arrive at the conclusion of the claimed invention. One would be motivated to incorporate OL’s signing key generation based on a hierarchy beginning with a root key into Guo, Chen, and Netwoven’s combined method for providing users access to a shared account. This combined functionality would ensure that the private key used to sign the certificate was verifiably originated within the signing device (IHS).
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Guo in view of Chen, Netwoven, and Seidl et al. (US 20180241740 A1), hereinafter Seidl.
Regarding Claim 12:
The combination of Guo, Chen, and Netwoven teaches the IHS of claim 1.
The combination of Guo, Chen, and Netwoven does not expressly teach wherein authenticating for logon access to the ALR further includes granting access to the ALR if the signed digital certificate is stored in a storage device external to the IHS.
However, Seidl teaches wherein authenticating for logon access to the ALR further includes granting access to the ALR if the signed digital certificate is stored in a storage device external to the IHS (Seidl – Paragraph [0048]: The digital certificate signed at step 27 is provided to the client 12 (in message 28); and Paragraph [0049]: The client 12 may be implemented as a software module and may be provided either on the client hardware directly or on e.g. a SIM card or on a so-called IDM Satellite. An IDM satellite may, for example, be provided in a removable form, for example as a memory stick (such as a USB stick); and Paragraph [0038]: A goal of identity management (IDM) (sometimes referred to as identity federation) is to enable users of one domain to access data or systems of another domain seamlessly and securely, and without the need for redundant user administration. Eliminating the need for repeated login procedures each time a new application or account is accessed can substantially improve the user experience).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Guo, Chen, and Netwoven, further incorporating Seidl to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Seidl’s teaching to allow access to an account in the case that the signed digital signature for verification is stored on an external storage device into Guo, Chen, and Netwoven’s combined system for providing users access to a shared account. This combined functionality would allow users the option to carry portable authentication credentials in external storage devices for the convenience of verified users within the system.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Guo in view of Chen, Netwoven, and Roper et al. (US 20190268325 A1), hereinafter Roper.
Regarding Claim 13:
The combination of Guo, Chen, and Netwoven teaches the IHS of claim 1.
The combination of Guo, Chen, and Netwoven does not expressly teach wherein authenticating for logon access to the ALR includes requiring a button on a chassis of the IHS is pushed.
However, Roper teaches wherein authenticating for logon access to the ALR includes requiring a button on a chassis of the IHS is pushed (Roper – Paragraph [0018]: The user, through the sign-on interface, is asked to press a button 122 located on the device 120. This generates a response from the device 120 signed with the keys 121 from the secure memory, and the signed response provided from the device 120 back to the authenticator 113. Based on the signed response received and the expected identity for the user (obtained from the first factor authentication), the authenticator authenticates the user in a second factor of authentication).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Guo, Chen, and Netwoven further incorporating Roper to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Roper’s teaching requiring a user to press a button on their device to initiate a login into Guo, Chen, and Netwoven’s combined system for securely providing users access to a shared account. This combined functionality would further enhance the security of the system by adding another feature to authenticate a user attempting to access the shared account.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Tashian (Tashian, C. (2021, September 16). SSH emergency access. Wayback Machine. https://web.archive.org/web/20220630185051/https://smallstep.com/blog/ssh-emergency-access/) teaches a break glass procedure for accessing SSH hosts in case of system access emergencies, including generating keys and corresponding certificates to authenticate access
Misra et al. (US 5757920 A) teaches techniques for providing logon certificates to authenticated users that include the user’s credentials that are decrypted and check upon attempt access
Cheung et al. (US 9166777 B2) teaches a system and method for authenticating users based on PKI credentials (including certificates) in addition to other user credentials
Johansson et al. (US 7602910 B2) teaches systems and methods for password protection involving public and private key certificates used for digital signature logon operations
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 PM.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/NICHOLAS JOSEPH DILUZIO/Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
