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 . In communications filed on 12/31/2025. Claims 1, 3-4, 13, 15-16, , and 20 are amended. Claims 1-20 are pending in this examination.
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 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. This examination is in response to US Patent Application No. 18/539,667.
Information Disclosure Statement
The listing of references in the specification (Paragraph 11) are not a proper information disclosure statement. 37 CFR 1.98(b) requires a list of all patents, publications, or other information submitted for consideration by the Office, and MPEP § 609.04(a) states, "the list may not be incorporated into the specification but must be submitted in a separate paper." Therefore, unless the references have been cited by the examiner on form PTO-892, they have not been considered.
Examiner Note
Applicant’s submitting a correction to drawing obviates previously raised Drawing objection.
The processor has been described in the specification as: [0034] In some arrangements, the processing circuit 312 includes a processor 314 and a memory 316. The processor 314 is implemented as a general-purpose processor, an Application Specific Integrated Circuit (ASIC), one or more Field Programmable Gate Arrays (FPGAs), a Digital Signal Processor (DSP), a group of processing components, or other suitable electronic processing components.
Response to Argument
Applicant’s arguments with respect to independent claims for newly added limitation have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Frist set of rejection:
Claims 1-3, 5-7, 9, 11-15, 17-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2019/0356650) issued to Leavy, and in view of US Patent No. (US9,203,616) issued to Brown .
Regarding claims 1, 13, and 20, Leavy discloses a method, comprising splitting Application Security Parameters (ASP) of an application into a first number of splits, wherein the first number of splits is identified by an Application Identifier (AID) of the application and the AID identifies the application for which the ASP is to be applied; storing each of the first number of splits and the AID in a respective one of a plurality of secure storages; retrieving a second number of splits from the plurality of secure storages using the AID in response to the plurality of secure storages authenticates or authorizes the AID [¶9, In order to ensure that the client-side application is unable to decrypt the locally stored encrypted application data prior to authenticating with an external authentication source (i.e., SSO, IdP), the client-side application divides the random encryption key into at least a first share and a second share according to a secret sharing algorithm. The first share is transmitted to a trusted third party, where the first share is stored securely until such time that the client-side application passes authentication and the trusted third party returns the first share to the client device. Meanwhile, the second share is encrypted locally and stored in a secure location on the client device], and [¶¶35-36, To prevent a malicious actor from being able to recover the encrypted client-side application data, the client-side application protects the local encryption key by dividing the local encryption key into a plurality of shares in block 240. The local encryption key is divided according to a secret sharing algorithm. In preferred embodiments, the secret sharing algorithm is any linear secret sharing scheme. One example of a linear secret sharing scheme is an exclusive-OR (XOR) secret sharing scheme, which begins with the client-side application generating a random string. The random string is a first share. A Boolean operation, such as an XOR, is performed using the random string and the local encryption key to form the second share. An XOR secret sharing scheme produces the at least two shares faster and computationally more-efficient than other secret sharing algorithms. In another example, the linear secret sharing scheme is Shamir Secret Sharing Scheme. Shamir Secret Sharing Scheme allows for a more expressive threshold access structure by allowing for the reconstruction of the local encryption key using t out of n number of shares. That is, Shamir Secret Sharing Scheme allows for the reconstruction of the local encryption key with less than all of the shares. This allows for the local encryption key to be recovered in the event that one of the plurality of shares is unavailable, for example, due to the repository being unavailable], and [¶39, In block 320, the server-side application receives account information and a first share from the first device. The account information includes information generated by the client-side application, such as at least one public signature verification key, an application identifier, etc. The first share is one of a plurality of pieces of information needed to regenerate the local encryption key on the first device. In block 330, the server-side application encrypts the account information and the first share. In block 340, the server-side application stores the encrypted user registration information and first share. In preferred embodiments, the encrypted registration information and first share are stored in the database entry created for the new account], and [¶55, Fig. 8, Data stored by memory 804 includes database 834… , database 834 indexes information related to the secure collaboration application, such as key information (e.g. a user signing key, an application signing key, etc.), user information (e.g., username, application identifier, etc.)…].
and determining the ASP by reassembling the second number of splits, wherein the application is configured to be launched or updated using the ASP [¶10, Upon successful authentication, the trusted third party returns the second share to the client device. The client-side application derives the random encryption key and decrypts the encrypted client-side application data. The decrypted client-side application data is used by the client-side application to access the corresponding server-side application. By dividing the key used to encrypt the client-side application data and storing one of the secret shares necessary to deriving the key at a trusted third party].
While leavy discloses Wherein the ASP comprises a password [¶8, The present disclosure describes techniques that allow for a client-side application, located on a first client device, to generate a random encryption key and encrypt client-side application data with the random encryption key. The random encryption key is used in lieu of a password-derived encryption key].
Leavy does not explicitly disclose Wherein the ASP comprises a password, however,
Brown discloses [Col.1 lines 63-67, when storing or authenticating a password, the client application splits the password and sends one share to each of the servers and neither of the servers is ever in possession of both password shares or the original password or password hash ].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Leavy, by incorporating “splitting a password”. as taught by Brown. One could have been motivated to do so in order to improve security, some systems mathematically split each password hash into two pieces of data (“shares”), such that each share on its own conveys no information about the original password hash. These systems store each share in a different database that may be in a different physical location and protected by different security measures [ Brown , Col.1 lines 40-45].
Regarding claims 2, and 14, Leavy discloses wherein each of the first number of splits is encrypted, and each of the first number of encrypted splits is stored in the respective one of the pluralities of secure storages [¶36, After generating the first and second shares, the first device transmits the first share to a trusted third party in block 250. In preferred embodiments, the first device encrypts the first share before transmitting to the trusted third party. In some examples, the first share is encrypted with a key derived according to Elliptic Curve Diffie-Hellman using a first ephemeral asymmetric key pair of the first device and a second ephemeral asymmetric key pair of the trusted third party].
Regarding claims 3, and 15, Leavy discloses, wherein the ASP comprises binary data, wherein the binary data comprises at least one of a symmetric key, an asymmetric private key, or a critical security parameter [¶34, After generating the local encryption key, the client-side application encrypts client-side application data using the local encryption key in block 230. The encrypted client-side application data is stored in a memory of the first device. The client-side application uses the local encryption key and a symmetric encryption algorithm to encrypt client-side application data… In alternative embodiments, a simple block cipher, such as the Advanced Encryption Standard (AES), the Data Encryption Standard (DES), Triple-DES (3DES), etc., is used to encrypt the client-side application data.].
Regarding claims 5, and 17, Leavy discloses, wherein the ASP is used in a Database Encryption Key Management (DBEKM) scheme [¶34, In alternative embodiments, a simple block cipher, such as the Advanced Encryption Standard (AES), the Data Encryption Standard (DES), Triple-DES (3DES), etc., is used to encrypt the client-side application data. Client-side application data includes, for example, a database associated with the client-side application, user information, personal identifying information (PII), communications received via the client-side application, or any combination thereof. In some embodiments, client-side application data includes a local database key such that the local encryption key is a key-encrypting key that is used to encrypt the local database key. Encrypting client-side application data ensures that client-side application data is secure. Thus, if the client device is ever compromised (i.e., stolen, lost, hacked, etc.), the encrypted client-side application data will be in an unusable state to the malicious actor].
Regarding claim 6, Leavy discloses, wherein the second number of splits are stored in a volatile memory of an application computing system; the determined ASP is stored in the volatile memory; and in response to determining that the ASP has already been used by the application, destroying the ASP in the volatile memory [¶36, In embodiments where more than two shares are formed, one share is sent to a trusted third party and another share is sent to a second device controlled and trusted by a user of the first device. The first share is then deleted by the first device in block 260. Preferably, the first share is forensically deleted such that the first share cannot be recovered on the first device. In block 270, the second share is stored securely on the first device. Because the local encryption key is not recoverable with only the second share, the first device may store the second share unencrypted. Alternatively, the second share is encrypted using an encryption key belonging to the first user to provide an additional layer of security], and [¶43, In block 450, the first device retrieves the second share from a secure storage. In block 460, the first device derives the local encryption key using at least the first share received from the Trusted Third Party and the second share retrieved by the first device. The local encryption key is derived by combining the first share and the second share according to a secret sharing algorithm. As noted above, this may be as simple as XOR-ing the first share and the second share to derive the local encryption key. Alternatively, the local encryption key is derived according to one of the secrets sharing algorithms discussed above. Once the local encryption key is derived, the client-side application forensically deletes the first share so that the local encryption key cannot be rederived to access the encrypted client-side application data].
Regarding claims 7, and 18, Leavy discloses, wherein the first number and the second number are the same, the first number of splits are a first number of components, and the second number of splits are a second number of components [¶35, To prevent a malicious actor from being able to recover the encrypted client-side application data, the client-side application protects the local encryption key by dividing the local encryption key into a plurality of shares in block 240. The local encryption key is divided according to a secret sharing algorithm. In preferred embodiments, the secret sharing algorithm is any linear secret sharing scheme… in another example, the linear secret sharing scheme is Shamir Secret Sharing Scheme. Shamir Secret Sharing Scheme allows for a more expressive threshold access structure by allowing for the reconstruction of the local encryption key using t out of n number of shares…].
Regarding claim 9, Leavy discloses, wherein the ASP is split into the first number of splits using Shamir's secret sharing scheme [¶35, the linear secret sharing scheme is Shamir Secret Sharing Scheme. Shamir Secret Sharing Scheme allows for a more expressive threshold access structure by allowing for the reconstruction of the local encryption key using t out of n number of shares. That is, Shamir Secret Sharing Scheme allows for the reconstruction of the local encryption key with less than all of the shares. This allows for the local encryption key to be recovered in the event that one of the plurality of shares is unavailable].
Regarding claim 11, Leavy discloses, wherein at least one of: the ASP is used by the application to derive a cryptographic key; or the ASP is used by the application as a cryptographic key to encrypt data, decrypt data, sign data, sign crypt data, or establish a secure connection[¶8, The present disclosure describes techniques that allow for a client-side application, located on a first client device, to generate a random encryption key and encrypt client-side application data with the random encryption key.
Regarding claim 12, Leavy discloses, wherein the ASP is random.
[¶9, the client-side application divides the random encryption key into at least a first share and a second share according to a secret sharing algorithm].
Claims 4, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2019/0356650) issued to Leavy, and in view of US Patent No. (US9,203,616) issued to Brown (US9,203,616) ,and further in view of US Patent No. (U2014/0176733) issued to Awan.
Regarding claims 4, and 16 wherein the password configured to unlock an object containing at least one of encrypted passwords, encrypted symmetric keys, encrypted asymmetric private keys, encrypted public key certificates, or Certificate Pinning Lists (CPLs)
While leavy discloses this limitation as: [¶8, The present disclosure describes techniques that allow for a client-side application, located on a first client device, to generate a random encryption key and encrypt client-side application data with the random encryption key. The random encryption key is used in lieu of a password-derived encryption key]
And furthermore, Brown discloses [Col.1 lines 63-67, when storing or authenticating a password, the client application splits the password and sends one share to each of the servers and neither of the servers is ever in possession of both password shares or the original password or password hash ].
however, Leavy and Brown don not explicitly disclose, and Awan discloses [ See FIG4, ¶93, Launch Targeted Wrapped Application… As part of the wrapping process, each wrapped application is assigned a unique identifier.], and [ see FIG 25A, ¶257-259, a split-key based encryption technique may be employed for workspace and wrapped applications to secure data, even against device jail braking… the technique is referred to as a "split key" based technique because an encryption key, utilized by workspace and wrapped applications, is divided into multiple parts… a process for generating a split key for use by a workspace or wrapped application to encrypt data is described. A workspace or wrapped application is launched… The data storage encryption key may be a key that is unique to the workspace, shared among workspace and wrapped applications, unique to a particular application, unique to a particular mobile device 100, unique to a particular user, etc.… this symmetric encryption key is then split (block 2510) into at least two parts. A first part of the split symmetric encryption key is encrypted with a key, which is based on user credentials, workspace credentials, etc. (block 2512). For example, the first part of the symmetric encryption key may be encrypted using password-based encryption (PBE)…].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Leavy, and Brown by incorporating “password-based encryption (PBE)”, as taught by Awan. One could have been motivated to do so in order to employee split-key based encryption technique for a wrapped applications and the first part of many parts of the symmetric encryption key may be encrypted using password-based encryption (PBE) for securing data against device jail breaking [ Awan, ¶¶257-259].
Claims 8, 10, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2019/0356650) issued to Leavy, and in view of US Patent No. (US9,203,616) issued to Brown (US9,203,616), and further in view of US Patent No. (US2017/0244685) issued to Mirza.
Regarding claims 8, and 19, Leavy, and Brown do not explicitly disclose, however, Mirza discloses wherein the first number and the second number are different, and the second number is less than the first number, wherein the first number of splits are a first number of shares, and the second number of splits are a second number of shares [¶¶27-28, In a further embodiment, a particular payload 117 may need to be communicated to multiple recipient clients 104. In such an embodiment, the encryption application 114 may generate segments 131 from the payload 117 for each of the recipient clients 104. These segments 131 would then be encrypted using an encryption key 124 for a respective one of the recipient clients 104. The segments 131 may then be communicated to all of the recipient clients 104 using a broadcast or multicast message in the network 107…. In another embodiment, the encryption application 114 may communicate a payload 117 or stream of payloads 117 to multiple recipient clients 104 by generating segments 131 from a payload 117 encrypted with a symmetric encryption key 124], and [¶33, After encrypting the payload 117, in box 202, the encryption application 114 splits the encrypted payload 117 into multiple segments 131. In some embodiments, this includes dividing the encrypted payload 117 into segments 131 of a predefined size. In other embodiments, this includes dividing the payload 117 into segments 131 of varying size. In further embodiments, this includes dividing the payload into a predefined number of segments 131. The encryption application 114 may also split the encrypted payload 117 into segments 131 by another approach], and [¶¶19, 30, 34-35]
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Leavy , and Brown by incorporating “encryption key 124 index”. as taught by Mirza. One could have been motivated to do so in order to select the encryption key 124 from pool of encryption keys according to a sequence identifier 134 of a given segment 131 with predefined or varying sizes of the split encrypted payload to obfuscate sensitive data traversing the network, and man-in-the-middle attack [ Mirza, ¶¶2, 33-34].
Regarding claim 10, Leavy, and Brown do not explicitly disclose, however, Mirza discloses wherein each of the first number of splits has a same length as that of the ASP; and each of the second number of splits has a same length as that of the ASP [¶¶27-28, In a further embodiment, a particular payload 117 may need to be communicated to multiple recipient clients 104. In such an embodiment, the encryption application 114 may generate segments 131 from the payload 117 for each of the recipient clients 104. These segments 131 would then be encrypted using an encryption key 124 for a respective one of the recipient clients 104. The segments 131 may then be communicated to all of the recipient clients 104 using a broadcast or multicast message in the network 107…. In another embodiment, the encryption application 114 may communicate a payload 117 or stream of payloads 117 to multiple recipient clients 104 by generating segments 131 from a payload 117 encrypted with a symmetric encryption key 124], and [0033] After encrypting the payload 117, in box 202, the encryption application 114 splits the encrypted payload 117 into multiple segments 131. In some embodiments, this includes dividing the encrypted payload 117 into segments 131 of a predefined size. In other embodiments, this includes dividing the payload 117 into segments 131 of varying size. In further embodiments, this includes dividing the payload into a predefined number of segments 131. The encryption application 114 may also split the encrypted payload 117 into segments 131 by another approach], and [¶¶19, 30, 34-35].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Leavy, and Brown by incorporating “encryption key 124 index”. as taught by Mirza. One could have been motivated to do so in order to select the encryption key 124 from pool of encryption keys according to a sequence identifier 134 of a given segment 131 with predefined or varying sizes of the split encrypted payload to obfuscate sensitive data traversing the network, and man-in-the-middle attack [ Mirza, ¶¶2, 33-34].
Second Set of Rejection:
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 of this title, 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent No. (US2022/0321339) issued to Yedluri, and in view of US Patent No. (US2014/0173700) issued to Awan, and further in view of US Patent No. (US2020/0372149) issued to Di Pietro.
Regarding claims 1, 13, and 20 , Yedluri discloses a method comprising storing each of the first number of splits and the AID in a respective one of a plurality of secure storages; retrieving a second number of splits from the plurality of secure storages using the AID in response to the plurality of secure storages authenticates or authorizes the AID [¶52, The client computing system 103 may comprise a processing device 174 operatively coupled to a communication device 172 and a memory device 176, the memory device 176 comprising data storage 178 and computer readable instructions 180. The computer readable instructions 180 may comprise a user application 182, which in some embodiments may be an application with a graphical interface that may allow the user 104 to access the functions of the CAAS server 101 and/or the hardware security module 102. In this regard, the user application 182 may allow the user 104 to transmit requests to retrieve an encryption key associated with the client computing system 103 and/or the user application, perform encryption and/or decryption of data, and the like.], and [ see FIG 2, ¶¶67-71, the process begins at block 201, where the system receives a request, from a client computing system, for a wrapping key split… The process continues to block 202, where the system generates, using a hardware security module, an encryption key associated with the client computing system and a wrapping key… The process continues to block 203, where the system splits the wrapping key into a plurality of wrapping key parts using a cryptographic algorithm… The process continues to block 204, where the system transmits a first wrapping key part from the plurality of wrapping key parts to the client computing system… The process continues to block 205, where the system stores a second wrapping key part and a third wrapping key part from the plurality of wrapping key parts in a cryptographic database]; and
and determining the ASP by reassembling the second number of splits, wherein the application is configured to be launched or updated using the ASP [ see FIG 3, ¶¶72-76, The process begins at block 301, where the system receives a request, from a client computing system, for access to the encryption key…. The process continues to block 302, where the system retrieves the plurality of wrapping key parts and the encryption key from the cryptographic database… The process continues to block 303, where the system reconstructs the wrapping key from the second wrapping key part and the third wrapping key part. It should be noted that even though the plurality of wrapping key parts comprises more than the second wrapping key part and the third wrapping key part, the two wrapping key parts may nevertheless be enough to reconstitute the server-side wrapping key… The process continues to block 304, where the system encrypts the encryption key using the wrapping key to generate a wrapped encryption key. The process concludes at block 305, where the system transmits the wrapped encryption key and at least one of the second wrapping key part and the third wrapping key part to the client computing system].
Yedluri does not explicitly disclose, however, Awan discloses splitting Application Security Parameters (ASP) of an application into a first number of splits, wherein the first number of splits is identified by an Application Identifier (AID) of the application, and the AID identifies the application for which the ASP is to be applied [ See FIG4, ¶93, Launch Targeted Wrapped Application… As part of the wrapping process, each wrapped application is assigned a unique identifier.], and [ see FIG 25A, ¶257-259, a split-key based encryption technique may be employed for workspace and wrapped applications to secure data, even against device jail braking… the technique is referred to as a "split key" based technique because an encryption key, utilized by workspace and wrapped applications, is divided into multiple parts… a process for generating a split key for use by a workspace or wrapped application to encrypt data is described. A workspace or wrapped application is launched… The data storage encryption key may be a key that is unique to the workspace, shared among workspace and wrapped applications, unique to a particular application, unique to a particular mobile device 100, unique to a particular user, etc.… this symmetric encryption key is then split (block 2510) into at least two parts. A first part of the split symmetric encryption key is encrypted with a key, which is based on user credentials, workspace credentials, etc. (block 2512). For example, the first part of the symmetric encryption key may be encrypted using password-based encryption (PBE)…].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Yedluri by incorporating “password-based encryption (PBE)”, as taught by Awan. One could have been motivated to do so in order to employee split-key based encryption technique for a wrapped applications and the first part of many parts of the symmetric encryption key may be encrypted using password-based encryption (PBE) for securing data against device jail breaking [ Awan, ¶¶257-259].
Yedluri , and Awan do not explicitly disclose, however Di Pietro discloses wherein the ASP comprises a password Di Pietro ( US2020/0372149) [¶14, The present disclosure provides for secure online account access recovery through the utilization of secret splitting and multiple secret recovery resources. The provided system helps provide increased and more flexible security as compared to typical account recovery systems. A website or application platform may utilize the provided system to enable users to regain access to registered accounts for which they have forgotten or lost their login credentials, such as their password. In response to a user requesting an account or password reset, the provided system may generate a secret, store the secret, and also split the secret into a set of tokens via a secret sharing function. The quantity of tokens that the secret is split into is adjustable. The secret sharing function can reconstruct the secret using a predetermined threshold quantity of the set of tokens. This predetermined threshold quantity is adjustable and may be less than the quantity of tokens in the set of tokens], and [see FIGS. 1, 3, ¶¶ [¶¶39-40, The authentication controller 114 additionally inputs the temporary password into the Shamir's Secret Sharing function, which splits the temporary password into three unique tokens (block 312). In this example, the Shamir's Secret Sharing function is programmed with a reconstruction threshold of all three tokens. The authentication controller 114 then transmits one token to the secret recovery resource 130A (e.g., the user's first email address), one token to the secret recovery resource 130B (e.g., the user's second email address), and one token to the secret recovery resource 130C (e.g., the user's mobile phone number) (block 314). Once the tokens are transmitted, the user obtains the tokens from the user's email address accounts and mobile phone via one or more of the user's devices (block 316). The user then transmits the tokens to the authentication controller 114 via the user device 104 (block 318).The authentication controller 114 determines a reconstructed password based on the three tokens and the Shamir's Secret Sharing function (block 320). Since all three tokens were transmitted, the predetermined threshold of tokens is met and the reconstructed password is obtained], and [Abstract].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teaching of Yedluri, Awan by incorporating “splitting a temporary password into three unique tokens”, as taught by Di Pietro. One could have been motivated to do so in a case If a malicious attacker were to attempt to impersonate a user by requesting a password reset of the user's account, the malicious attacker would need to obtain a sufficient quantity of tokens from the user's various recovery resources in order to gain access to the user's account. Obtaining the tokens would require the malicious attacker to compromise more than one, and possibly many, recovery resources, which decreases the likelihood that the malicious attacker is able to gain access to the user's account as compared to the malicious attacker needing to compromise only a single recovery resource to do so in typical account recovery methods. This decrease in likelihood increases the level of security provided by the presently disclosed system.[Di Pietro, ¶¶16].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
See submitted 892 for more relevant references.
SINGH ( US11797686) [Col.23 lines 57-67; Col.24 lines 1-12, At 806, resource access application 424 may monitor user navigation activity. For example, resource access application 424 may monitor navigation events and determine whether the navigation is to a corporate resource or a personal resource. At 808, resource access application 424 may detect a user login event. If, at 810, resource access application 424 detects a login to a corporate resource, then, at 812, resource access application 424 may update the corporate password data structures. For example, resource access application 424 may segment a password (e.g., corporate password) that was input by user 510 to login to the corporate resource into one or more substrings of different lengths. Resource access application 424 may then add each substring of a specific length to a corporate password substring data structure (e.g., one of Bloom filters 702a-702d or another Bloom filter) that is being used for recording substrings of the specific length of the substring that is being added, as previously described herein. Adding the substrings of the input corporate password to an appropriate corporate password substring data structure in this manner updates the record of the corporate passwords belonging to user 510. Resource access application 424 may then continue monitoring user navigation activity, at 806].
MIYATA ( US2016/0330018) [0025] Secret sharing is a technique of converting data into a plurality of shared values, allowing the original data to be recovered when a specified number of shared values or more is used, and disallowing recovery of the original data when the number of shared values is less than the specified number. A (k, n) secret sharing is a type of secret sharing in which input plaintext is split into n shared values, the n shared values are given to n calculation entities, the plaintext can be recovered if k shared values are combined, and no information of the plaintext can be obtained from fewer-than-k shared values, where n and k are integers not less than 1 and satisfy n≧k. A typical example of (k, n) secret sharing is Shamir secret sharing], and [¶¶37-41, FIG. 5 illustrates a procedure in which the registrant terminal 2 registers target data for data processing in the secure computation servers 1.sub.1 to 1.sub.n.
[0038] The storage 16 of the secure computation server 1.sub.i (i=1 to n) stores an i-th shared value of n shared values obtained by splitting a password specified for an informant using the registrant terminal 2 or an information analyst using the user terminal 3. Hereafter, the password of the informant will be referred to as a registered password, and n shared values obtained by splitting the registered password will be referred to as registered-password shared values. The password of the information analyst will be referred to as a utilization password, and n shared values obtained by splitting the utilization password will be referred to as utilization-password shared values. The method of sharing the password needs to be a secret sharing scheme that can use the secure computation-based authentication technique described earlier. For example, the secret sharing scheme described in Reference literature 5, described above, can be applied. In step S20a, the authentication request section 20 of the registrant terminal 2 allocates, to the n secure computation servers 1.sub.1 to 1.sub.n, n shared values obtained by splitting a password input by the informant. Hereafter, the password input by the informant will be referred to as a registration input password, and n shared values obtained by splitting the registration input password will be referred to as registration input password shared values. To allocate means to send an i-th registration input password shared value, where i is an integer between 1 and n, both inclusive, to an i-th secure computation server 1.sub.i through the communication channel. In step S10a, the authentication execution section 10 of the secure computation server 1.sub.i verifies whether the registration input password agrees with the registered password, by using the registration input password shared value received from the registrant terminal 2 and the registered password shared value stored in the storage 16. At least k of the n secure computation servers 1.sub.1 to 1.sub.n should work in cooperation with one another to execute step S10a. For a specific password verification method, refer to Reference literature 4, described above. In step S10b, if it is determined that the registration input password agrees with the registered password, the authentication execution section 10 of the secure computation server 1.sub.i sends to the registrant terminal 2 the result of authentication indicating that authentication has been successful. If it is determined that the registration input password does not agree with the registered password, the result of authentication indicating that authentication has failed is sent to the registrant terminal 2.
Triandopoulos ( US11115196) [ see FIG 1, Col. 7 lines 4-29, a password-based key-splitting scheme for user credential protection in mobile computing settings. Generally, one cryptographically strong key is employed for protecting sensitive data, where this key is split into two or more shares dispersed among a set of devices, such as mobile devices, smart objects and/or online servers. Access to data protected by such a split key is granted only through the reconstruction of this split key, where (typically for security and usability reasons) one of the employed shares can receive a fixed value which is associated with or derived by some predetermined, possibly private, information related to the user (e.g., a password). For instance, if Shamir's (t, n) threshold secret sharing scheme is used for splitting the key into n shares, a combination of any t, or more, such shares is necessary to reconstruct the key, but now one of the shares may be user-defined and provided directly by the user. Overall, both security and usability are improved by leveraging splitting of a cryptographic key into a number of individually managed and protected shares, to provide stronger resilience against device compromises and state leakage, and by associating at least one of these shares with a user password (or personal identification number (PIN) or another user-defined secret), to allow reconstruction of the split key conditioned on the knowledge of such password (or other user-defined secret information)].
Bansal (US2022/0215087) [¶61, One or more of applications 119 may include one or more algorithms that encrypt information, process received executable instructions, interact with enterprise systems, perform power management routines or other suitable tasks. Algorithms may be used to perform the functions of one or more of the audio file generation, password compression, password decompression, split byte generation, packet joining and packet fragmentation, and/or perform any other suitable tasks.
Longobardi ( US2013/0061298) [ see FIG.3, ¶¶52-54, After receiving the selected session key identification number from authentication server device 304, client device 302 uses a secure software application, such as password authentication manager 218 in FIG. 2, to establish a predetermined number of parallel communication channels, such as communication channels 310, with authentication server device 304 based on the particular set of parameters identified by the selected session key identification number. Further, the password authentication manager application automatically segments password 308 into a predetermined number of password segments, such as password segments 312. In addition, the password authentication manager application may encrypt each password segment in password segments 312. Alternatively, the password authentication manager application may encrypt password 308 prior to segmentation of password 308. Furthermore, the password authentication manager application may rearrange or mix up password segments 312 in an out-of-order sequence. Then, the password authentication manager application sends each password segment in password segments 312 to authentication server device 304 via one communication channel in communication channels 310 in parallel at a same time… ] Authentication server device 304 decrypts each of the received password segments 312 and reconstructs password 308 to form reconstructed password 314 by rearranging the mixed up out-of-order password segments based on the particular set of parameters identified by the selected session key identification number, which has been agreed upon prior to establishing the session. …].
Shemer (US2020/0119911) [ 0064] In one embodiment of the invention, the key splitter (606) may be a computer program or process (i.e., an instance of a computer program) that executes on the underlying hardware of the TKA (600). Specifically, the key splitter (606) may be a computer program or process tasked with the generation of split private keys from a given private key (generated by the key generator (604)). A split private key may represent a share of the given private key from which the split private key is based. Each share alone cannot fully decrypt data (encrypted using the matching public key). Instead, a combination of all shares or all split private keys are necessary to decrypt the encrypted data. Further, towards generating split private keys from a given private key, the key splitter (606) may employ any existing or future developed key splitting or secret sharing technique. By way of an example, the key splitter (606) may employ the exclusive OR (XOR) method, which for generating two split private keys would entail: (i) obtaining a to-be-split private key; (ii) generating the first split private key using random bits, where the length of the first split private key matches the length of the to-be-split private key; and (iii) generating the second split private key by performing an XOR bitwise operation between the to-be-split private key and the first split private key.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHAHRIAR ZARRINEH whose telephone number is (571)272-1207. The examiner can normally be reached Monday-Friday, 8:30am-5: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, Jorge Ortiz-Criado can be reached at 571-272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SHAHRIAR ZARRINEH/Primary Examiner, Art Unit 2496
Prosecution Insights