DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after 16 March 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in reply to papers filed on 15 October 2024. Claims 1, 14, and 20 are independent. Claims 1-20 are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As per claim 1:
Claim 1 recites: “… operatively coupled to the at least one memory device and the at least one communication device …”. The term “the at least one communication device” makes the claim indefinite as it lacks proper antecedent basis.
Furthermore, claim 1 previously recites “a memory device with computer-readable program code stored thereon”, and does not recite ‘at least one memory device’. Thus, the term “the at least one memory device” makes the claim indefinite as it lacks proper antecedent basis.
As per claims 1, 14, and 20:
Claims 1, 14, and 20 recite: “… identify at least one vault identifier, wherein the vault identifier is associated with a vault … a vault associated with the vault identifier …”. Because claims 1, 14, and 20 introduce “at least one vault identifier”, it is unclear whether each subsequent recitation of the singular “the vault identifier” refers to the “at least one vault identifier” collectively, or to a single one of a plurality of vault identifiers.
As per claims 1, 14, and 20:
Claims 1, 14, and 20 recite: “… a vault comprising at least one authentication credential … vault data for a vault associated with the vault identifier …”. It is unclear whether the second recitation of “a vault” refers to the same vault as the first recitation, or to a different vault. Each subsequent recitation of “the vault” in claims 1, 14, and 20 is indefinite because it cannot be determined which of the two recited vaults is referenced.
As per claims 2-3, 15-16, and 18:
Claims 2-3, 15-16, and 18 each recite the limitation “the shared authentication credential”. The independent claims from which claims 2-3, 15-16, and 18 depend, recite “at least one shared authentication credential” and does not recite a singular ‘a shared authentication credential’. Thus, the term “the shared authentication credential” make the claims indefinite as it lacks proper antecedent basis.
As per claims 9-10:
Claims 9 and 10 each recite the limitation “the shared authentication credential of the vault”. Claim 1 recites “at least one shared authentication credential” rather than a singular ‘a shared authentication credential’, and further recites two separate occurrences of “a vault”. There is insufficient antecedent basis for these limitations in the claims, and it cannot be determined which of the two recited vaults is referenced.
As per claims 14-15 and 18-19:
Claim 14-15 and 18-19 recite: “… cause the processor to …”. The term “the processor” makes the claim indefinite as it lacks proper antecedent basis.
As per claims 2-13 and 15-19:
Independent claims 1 and 14 are rejected under 35 U.S.C. 112(b), as stated above, as being indefinite for failing to particularly point out and distinctly claim the subject matter. Thus, claims 2-13 and 15-19 are rejected under 35 U.S.C. 112(b) by virtue of their dependency from claims 1 and 14, respectively.
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 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.
The factual inquiries 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-2, 4, 6, 8-10, 14-15, 17-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Khaund et al., US 2022/0318370 A1 (hereinafter, “Khaund ‘370”), in view of Pangam et al., US 2018/0176195 A1 (hereinafter, “Pangam ‘195”), and further in view of Abu Asba et al., US 2020/0228412 A1 (hereinafter, “Asba ‘412”).
As per claim 1: Khaund ‘370 discloses:
A system for automatically and dynamically updating and managing authentication credential in a distributed network (a cloud computing system 102 that automatically rotates secret information used by cloud-based applications to authenticate communications with external entities, where the cloud computing system 102 includes dependent system resources 116 and dependent services 118 that are distributed within the networked environment [Khaund ‘370, ¶¶Abstract, 15, 22; Fig.1]),
the system comprising: a memory device with computer-readable program code stored thereon (a system memory 830 of a computer 810, the system memory including computer readable media storing program modules and program data that are executable by the computer 810 [Khaund ‘370, ¶¶59, 69-70; Fig.6]);
at least one processing device operatively coupled to the at least one memory device and the at least one communication device, wherein executing the computer-readable code is configured to cause the at least one processing device to: (a processing unit 820 of the computer 810 coupled to the system memory 830 by a system bus 821, where the processors and servers include computer processors with associated memory that are activated by the other components of the system [Khaund ‘370, ¶¶59, 69; Fig.6])
identify at least one (a secret rotation identifier 160 that intermittently scans the rotation schedule or rotation criteria to determine whether any secrets stored in a secrets data store 128 are to be rotated, and that selects one of those secrets or sets of secrets for rotation, where the secrets data store 128 stores secrets 168 including digital certificates 172, encryption keys 174, passwords 176, and connection strings 178 [Khaund ‘370, ¶¶36-37, 41, 48; Fig.2-3]);
access, (accessing, from the secrets data store 128, the secrets 168 stored therein together with other items 170 stored in the data store 128, such as the expiration schedules or expiration criteria for those secrets, where each category or type of secret has its own rotation schedule that dictates when the secrets are to be changed or rotated [Khaund ‘370, ¶¶25, 36-37, 41; Fig.2]);
generate, based on the at least one (determining the dependent services 118 and dependent system resources 116 that use that particular secret, or that are dependent on that particular secret, where whitelisting logic 146 whitelists the new secret for those dependent services 118 and dependent system resources 116 [Khaund ‘370, ¶¶22, 32, 54; Fig.1-2]); and
As stated above, Khaund ‘370 does not explicitly disclose the limitations “… identify at least one vault identifier, wherein the vault identifier is associated with a vault … access, based on the at least one vault identifier, vault data for a vault associated with the vault identifier … generate, based on the at least one vault identifier and the vault data, a vault tree comprising a hierarchical organization of the vault and associated vault dependencies … configure, based on the vault tree, a vault rotation user interface with the vault tree, wherein the vault rotation user interface comprises the vault tree at a current time with the at least one shared authentication credential”.
Pangam ‘195, however, discloses:
… identify at least one vault identifier, wherein the vault identifier is associated with a vault … (under the broadest reasonable interpretation, a “vault identifier” may be interpreted as an identifier that uniquely identifies an entity under which authentication credentials are stored (i.e., an application identifier that uniquely identifies an application and the functional accounts and corresponding passwords stored in association therewith); a functional account information table 118 that stores, for each functional account, a functional account identifier, in the form of a string which uniquely designates the particular functional account of the entity application, an application identifier, which uniquely identifies the entity application to which the functional account is associated, and a password representation, in the form of a string representing the password for the functional account; an entity application information table 120 that stores, for each application identifier, an application name and a list of functional account identifiers that identify the particular functional accounts that are associated with the entity application; the functional account identifier and password data are further stored in a cryptographic vault of the entity 130 in the form of labels, where the labels are used as a source from where passwords are referred during the processing of a request [Pangam ‘195, ¶¶37-38, 65, 85; Fig.1])
… access, based on the at least one vault identifier, vault data for a vault associated with the vault identifier … (in response to receiving the entity application details, transmitting to the user device 102 data representing a list of supported functional accounts associated with the selected entity application 105 for which password management can be performed; and retrieving, from the functional account information table 118 of the repository 116, the stored functional account data corresponding to the functional account that is to be updated, including the corresponding password data [Pangam ‘195, ¶¶54, 65, 77; Fig.6])
… generate, based on the at least one vault identifier and the vault data, associated vault dependencies … (the updater module 110 retrieving the stored functional account data on the basis of the functional account identifier and the application identifier of the entity application with which the functional account is associated, and thereafter processing the retrieved functional account data to generate new password data [Pangam ‘195, ¶¶37-38, 54-55, 77])
Khaund ‘370 and Pangam ‘195 are analogous art because they are from the same field of endeavor, namely that of automatically updating and managing authentication credentials used by applications and services within a networked computing environment. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Khaund ‘370 and Pangam ‘195 before them, to modify the system in Khaund ‘370 to include the teachings of Pangam ‘195, namely to implement the secrets data store 128 of Khaund ‘370 such that each stored secret is associated with an identifier that uniquely identifies the application construct under which that secret and the other credentials of the associated accounts are stored, and such that the stored credential data is retrieved on the basis of that identifier prior to rotation, as disclosed in Pangam ‘195. A motivation for doing so would be to remove the need for the entity to separately schedule, organize and conduct password updates for each individual account, thereby increasing the convenience of managing each application account and promoting efficiency in the scheduling process (see Pangam ‘195, ¶¶22, 32).
As stated above, Khaund ‘370 in view of Pangam ‘195 does not explicitly disclose the limitations “… generate, … a vault tree comprising a hierarchical organization of the vault and associated vault dependencies … configure, based on the vault tree, a vault rotation user interface with the vault tree, wherein the vault rotation user interface comprises the vault tree at a current time with the at least one shared authentication credential”.
Asba ‘412, however, discloses:
… generate, … a vault tree comprising a hierarchical organization of the vault and associated vault dependencies … (generating a dependency assessment tree 700 from a database containing a plurality of PA entity records, where each PA entity record includes information specifying a logical location of the respective PA entity in the dependency assessment tree, where the dependency assessment tree takes the form of nodes and branches such that respective nodes correspond to the respective PA entities and branches connect nodes of PA entities between which there is a functional dependence; a first PA entity that depends on a second PA entity is referred to as a parent and the second PA entity is referred to as a child, where the respective nodes of the dependency assessment tree are arranged in a hierarchy of dependency levels comprising one or more nodes at one or more dependency levels below that of the first PA entity, one or more nodes at one or more dependency levels above that of the first PA entity, or a combination of both [Asba ‘412, ¶¶133, 135-136, 154, 159; Fig.7])
configure, based on the vault tree, a vault rotation user interface with the vault tree, wherein the vault rotation user interface comprises the vault tree at a current time with the at least one shared authentication credential. (transmitting to a client device a graphical representation of a first portion of the dependency assessment tree depicting the first PA entity, one or more dependency nodes having a functional dependency relationship with the first PA entity, and the connecting branches between the dependency nodes, such that the client device generates the corresponding tree view in the graphical user interface (GUI) of the client device; each PA entity record includes data for configuring the graphical representation of the respective PA entity on the GUI; the PA system is configured to update the dependency assessment tree in real time, such that an error condition affecting a PA entity is displayed on all nodes representing the PA entities that are affected and the removal of a PA entity from the PA system is reflected in the dependency assessment tree immediately by removing the associated mode therefrom; the tree view further includes GUI-based interactions and controls, such as drop-down menus and point-and-click selection, for graphically exploring the hierarchy of dependencies among user-selected PA entities and graphically identifying how changes to PA entities may ripple across dependencies; a default tree view displays top level node 702 and second level nodes 704; the recitation that the vault tree comprises “the at least one shared authentication credential” is set forth in the preceding limitation and is taught by Khaund ‘370 as stated above, with Asba ‘412 being relied upon for configuring the user interface with the generated vault tree, as stated below [Asba ‘412, ¶¶133, 137, 142, 154-157; Fig.7, Fig.9])
Khaund ‘370 (modified by Pangam ‘195) and Asba ‘412 are analogous art because Asba ‘412 is reasonably pertinent to the particular problem with which the inventor was concerned, namely that of identifying the components of a networked computing environment that are functionally dependent upon a common component such that the effect of a change to that component may be assessed before the change is made. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Khaund ‘370 (modified by Pangam ‘195) and Asba ‘412 before them, to modify the system in Khaund ‘370 (modified by Pangam ‘195) to include the teachings of Asba ‘412, namely to arrange the dependent services 118 and dependent system resources 116 that use a particular secret of Khaund ‘370 into a hierarchy of dependency levels in the manner of the dependency assessment tree of Asba ‘412, and further to transmit a graphical representation of that hierarchy to a client device such that the hierarchy is generated and displayed in a GUI of the client device, as disclosed in Asba ‘412. A motivation for doing so would be to make updating of the dependent components more robust against dependency-related errors while ensuring predictable functional outcomes of such changes, such that a user or administrator may make changes without having to directly or explicitly navigate the complexities of the functional dependencies (see Asba ‘412, ¶¶132-133).
As per claim 2: Khaund ‘370 in view of Pangam ‘195, and further in view of Asba ‘412 discloses all limitations of claim 1, as stated above, from which claim 2 is dependent upon. Furthermore, Khaund ‘370 discloses:
wherein executing the computer-readable code is configured to cause the at least one processing device to: identify a new authentication credential for the vault tree (once the ROTATE interface is called for the selected secret and the appropriate secret type-specific system 138 is woken up on the serverless platform, secret acquisition logic 144 acquires or generates the new secret [Khaund ‘370, ¶¶27, 31, 49, 54; Fig.4]);
and automatically rotate the shared authentication credential with the new authentication credential at the vault and the associated vault dependencies in the vault tree (whitelisting logic 146 whitelists the new secret for the dependent services 118 and dependent system resources 116 that use that particular secret; revocation logic 148 then communicates to those dependent services 118 and dependent system resources 116 that the new secret is ready and has been whitelisted for their access, and the dependent services and resources access the new secret and provide an indication that the old secret has been replaced by the new secret at those services and resources; upon receiving that acknowledgement, orchestration engine 126 stores the new secret in secrets data store 128; the system automatically rotates secrets in a way that is transparent to the consumers, such that at no point does a developer or other team personnel need to be involved [Khaund ‘370, ¶¶18, 27, 32, 50, 54-56; Fig.3, Fig.4]).
As per claim 4: Khaund ‘370 in view of Pangam ‘195, and further in view of Asba ‘412 discloses all limitations of claim 1, as stated above, from which claim 4 is dependent upon. Furthermore, Khaund ‘370 discloses:
wherein the vault rotation user interface is integrated with an application programming interface (API) (management system 134 exposes an application programming interface (API) 152 for interaction by other items, such as orchestration engine 126 and secrets data store 128; the API 152 implementing four different methods including ADD, ROTATE, DELETE and EXPIRYTIMELINE, where the ROTATE interface can be called to rotate a particular secret or set of secrets, and where management invocation logic 158 invokes management system 134 by making a “ROTATE” call on interfaces 152 such that, when an API call is received to rotate a secret, serverless control functionality 132 wakes up management system 134 in order to identify and execute the particular system logic that is to be executed in response to the “ROTATE” call; in the system of Khaund ‘370 as modified above, the rotation of the shared authentication credential presented at the vault rotation user interface is accordingly invoked by way of a call on the API 152 [Khaund ‘370, ¶¶33, 39, 48, 54; Figs.2-4]).
As per claim 6: Khaund ‘370 in view of Pangam ‘195, and further in view of Asba ‘412 discloses all limitations of claim 1, as stated above, from which claim 6 is dependent upon. Khaund ‘370 does not explicitly disclose the limitations of claim 6. Pangam ‘195, however, discloses:
wherein the identification of the at least one vault identifier further comprises: receiving the vault identifier from a user device, wherein the user device is configured with at least one of the vault rotation user interface or a vault identifier user interface (at step 408, the user 111 provides functional account information to the password management application 106 via the UI 103 of the user device 102; UI 103 is generated by the user device 102 to render display elements including text input forms and interactive application windows, and where the functional account information received from the user device 102 includes, for each functional account to be enrolled, a functional account identifier for the functional account and an entity application identifier of the entity application to which the functional account is associated; functional account data encapsulating that information being transmitted from the user device 102 to the password management device 104 [Pangam ‘195, ¶¶33, 65; Fig.1, Fig.4]).
Khaund ‘370 and Pangam ‘195 are analogous art because they are from the same field of endeavor, namely that of automatically updating and managing authentication credentials used by applications and services within a networked computing environment. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Khaund ‘370 and Pangam ‘195 before them, to modify the system in Khaund ‘370 to include the teachings of Pangam ‘195, namely to receive the identifier of the construct under which the authentication credentials are stored from a user device that is configured with a user interface for that purpose, as disclosed in Pangam ‘195. A motivation for doing so would be to obtain the details of each account that is to be managed by way of a registration process in which the user specifies those details, such that the system need not have prior knowledge of the accounts associated with a particular application (see Pangam ‘195, ¶¶28, 65).
As per claim 8: Khaund ‘370 in view of Pangam ‘195, and further in view of Asba ‘412 discloses all limitations of claim 1, as stated above, from which claim 8 is dependent upon. Khaund ‘370 does not explicitly disclose the limitations of claim 8. Pangam ‘195, however, discloses:
wherein the vault data is accessed by receiving the vault data from a user device (the functional account information received from the user device 102 further includes password data for each functional account, including a password representation, where the received functional account data 105 includes plaintext password data representing a plaintext password for each corresponding functional account that is to be managed; at step 504, the received functional account data is stored in the repository 116 by generating a secure representation for the plaintext password of each of the one or more functional accounts [Pangam ‘195, ¶¶65, 71; Fig.4, Fig.5]).
Khaund ‘370 and Pangam ‘195 are analogous art because they are from the same field of endeavor, namely that of automatically updating and managing authentication credentials used by applications and services within a networked computing environment. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Khaund ‘370 and Pangam ‘195 before them, to modify the system in Khaund ‘370 to include the teachings of Pangam ‘195, namely to access the credential data by receiving that data from a user device on which the user has provided it, as disclosed in Pangam ‘195. A motivation for doing so would be to obtain the details of each account that is to be managed by way of a registration process in which the user specifies those details, and thereafter to generate and store a secure representation of the received plaintext password rather than retaining the password in plaintext form (see Pangam ‘195, ¶¶28, 71).
As per claim 9: Khaund ‘370 in view of Pangam ‘195, and further in view of Asba ‘412 discloses all limitations of claim 1, as stated above, from which claim 9 is dependent upon. Khaund ‘370 does not explicitly disclose the limitations of claim 9. Pangam ‘195, however, discloses:
wherein executing the computer-readable code is configured to cause the at least one processing device to: receive, by a user device, a security code for the vault identifier (the user 111 accesses the password management application 106 by presenting their username in combination with a password management passcode, where the password management passcode is chosen by the user 111 at the time of registration with the password management system 100; at step 404, a registered user 111 logs into the password management application 106 by presenting their username and passcode combination [Pangam ‘195, ¶¶62-63; Fig.4]);
validate the security code with an authenticated security code of the vault identifier (the user information table 122 is checked to determine whether the user 111 is registered with the system; if the user 111 is registered, then the user information table 122 entry containing the presented username is extracted, and the stored passcode, which is stored in a secure form such as a hash value obtained by applying the SHA-1 algorithm to the passcode, is compared to the hash value produced from the passcode presented on login [Pangam ‘195, ¶¶62-63; Fig.4]);
and determine, based on the validation, a user of the user device is allowed access to the vault to rotate the shared authentication credential of the vault (if the hash values match, then the user 111 is authenticated and the login attempt is successful, otherwise the login attempt fails and further access to the password management application 106 is denied to the user 111; the password management system is thereby configured to allow authorized users of the entity application to access the data stored for all the corresponding functional accounts registered to the entity application; a user can perform updates of the password for any one or more of the functional accounts for a particular entity application via the password management system [Pangam ‘195, ¶¶30, 62-63; Fig.4]).
Khaund ‘370 and Pangam ‘195 are analogous art because they are from the same field of endeavor, namely that of automatically updating and managing authentication credentials used by applications and services within a networked computing environment. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Khaund ‘370 and Pangam ‘195 before them, to modify the system in Khaund ‘370 to include the teachings of Pangam ‘195, namely to require a user of a user device to present a passcode that is validated against a stored secure representation of that passcode before the user is permitted to access the stored credentials and to update them, as disclosed in Pangam ‘195. A motivation for doing so would be to ensure that the entity's services and the credentials stored in association therewith are accessible only to users with appropriate authorization, and to prevent unauthorized parties from accessing the application and/or its services (see Pangam ‘195, ¶¶5, 20).
As per claim 10: Khaund ‘370 in view of Pangam ‘195, and further in view of Asba ‘412 discloses all limitations of claims 1 and 9, as stated above, from which claim 10 is dependent upon. Khaund ‘370 does not explicitly disclose the limitations of claim 10. Pangam ‘195, however, discloses:
wherein the determination the user is allowed access to the vault comprises a determination the user is allowed access to view and interact with the (the password management system is configured to allow authorized users of the entity application to access the data stored for all the corresponding functional accounts registered to the entity application; a user can perform manual updates of the password for any one or more of the functional accounts for a particular entity application via the password management system, where an admin user manages the password update functionality configured for an entity application by accessing the password management system using their corresponding application account details [Pangam ‘195, ¶¶30, 63]).
Khaund ‘370 and Pangam ‘195 are analogous art because they are from the same field of endeavor, namely that of automatically updating and managing authentication credentials used by applications and services within a networked computing environment. For the reasons stated in claim 9, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Khaund ‘370 and Pangam ‘195 before them, to modify the system in Khaund ‘370 to include the teachings of Pangam ‘195.
As stated above, Khaund ‘370 in view of Pangam ‘195 does not explicitly disclose the limitation “… allowed access to view and interact with the vault tree in the vault rotation user interface”, as recited in claim 10.
Asba ‘412, however, discloses:
… allowed access to view and interact with the vault tree in the vault rotation user interface (the dependency assessment tree 700 includes GUI-based interactions and controls for graphically exploring the hierarchy of dependencies among user-selected PA entities and assessing the effect of modifications to PA entities in the tree; the graphical controls including interactive functions such as drop-down menus, point-and-click selection, and editing actions; a user may click on a node of the tree to filter out the branches extending from the remaining nodes in order to obtain a desired tree view, where filtering may be applied to any node on any level of the tree, and where the resulting tree view is generated in the graphical user interface (GUI) of the client device [Asba ‘412, ¶¶133, 137, 155-157; Fig.7]).
Khaund ‘370 (modified by Pangam ‘195) and Asba ‘412 are analogous art because Asba ‘412 is reasonably pertinent to the particular problem with which the inventor was concerned, namely that of identifying the components of a networked computing environment that are functionally dependent upon a common component such that the effect of a change to that component may be assessed before the change is made. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Khaund ‘370 (modified by Pangam ‘195) and Asba ‘412 before them, to modify the system in Khaund ‘370 (modified by Pangam ‘195) to include the teachings of Asba ‘412, namely to permit a user who has been determined to be authorized to view and to interact with the hierarchy of dependent components by way of the graphical controls of the tree view, as disclosed in Asba ‘412. A motivation for doing so would be to allow the tree to be displayed to users with limited screen size without unduly crowding the graphical user interface (see Asba ‘412, ¶137).
As per claims 14-15, 17-18, and 20: Claims 14-15 and 17-18 define a computer program product, and claim 20 defines a computer implemented method, that recite substantially similar subject matter as the system of claims 1-2, 6, and 9. Specifically, claim 14 is directed to a computer program product comprising at least one non-transitory computer-readable medium having computer-readable program code portions embodied therein, the computer-readable program code portions being executable by a processing device to cause the processor to perform the functions performed by the system of claim 1; claims 15, 17, and 18 recite the same subject matter as claims 2, 6, and 9, respectively; and claim 20 is directed to a computer implemented method comprising the steps performed by the system of claim 1. Thus, the rejection of claims 1-2, 6, and 9 is equally applicable to claims 14-15, 17-18, and 20, respectively.
Claims 3 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Khaund ‘370, in Pangam ‘195, further in view of Asba ‘412, and further in view of Aguilar-Macias et al., US 2016/0034684 A1 (hereinafter, “Macias ‘684”).
As per claim 3: Khaund ‘370 in view of Pangam ‘195, and further in view of Asba ‘412 discloses all limitations of claims 1-2, as stated above, from which claim 3 is dependent upon. Khaund ‘370 in view of Pangam ‘195, and further in view of Asba ‘412 does not explicitly disclose the limitations of claim 3. Macias ‘684, however, discloses:
wherein the automatic rotation of the shared authentication credential in the associated vault dependencies is based on receiving a sync user input at the vault rotation user interface (under the broadest reasonable interpretation, a “sync user input” may be interpreted as a user input received at a user interface in response to which an authentication credential is synchronized at the components associated with that credential (i.e., the submission of a user password change at the web-based user interface, in response to which the change discovery module 127 synchronizes the new password across the registered client devices 130); a change discovery module 127 that handles password synchronization across client devices 130 in response of a password change manually initiated by a user, as opposed to an automatic password generation initiated by the identity management system 120; change discovery module 127 detects user password changes made by the user within a user interface of the identity management system 120 itself; the identity management system 120 providing a web-based user interface to the user listing all of the user’s accounts on the third-party service systems 140 along with a password change user interface for each, such that upon submission of a user password change for one of the third-party service systems 140 using this user interface the change discovery module 127 notes the change, and thereafter causes configuration of the various client devices 130 that are registered to the user on the identity management system such that the client devices 130 store the new password for the application [Macias ‘684, ¶¶33-35; Fig.1]).
Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) and Macias ‘684 are analogous art because they are from the same field of endeavor, namely that of automatically updating and managing authentication credentials used to access accounts within a networked computing environment. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) and Macias ‘684 before them, to modify the system in Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) to include the teachings of Macias ‘684, namely to configure the user interface of the system to receive a user input submitted at that interface and, in response to that submission, to synchronize the credential at each of the components associated with that credential, as disclosed in Macias ‘684. A motivation for doing so would be to handle synchronization of the credential in response to a credential change manually initiated by a user, as opposed to a credential change initiated by the system, such that each component that is registered to use the credential is configured with the new credential in order for the user to continue to access the services provided by that component, and such that the credential change is invisible to the user and the user does not need to configure each component manually (see Macias ‘684, ¶¶29, 33).
As per claim 16: Claim 16 defines a computer program product that recites substantially similar subject matter as the system of claim 3. Specifically, claim 16 is directed to a computer program product in which the automatic rotation of the shared authentication credential in the associated vault dependencies is based on receiving a sync user input at the vault rotation user interface, as performed by the system of claim 3. Thus, the rejection of claim 3 is equally applicable to claim 16.
Claims 5 and 7 are rejected under 35 U.S.C. 103 as being unpatentable over Khaund ‘370, in view of Pangam ‘195, further in view of Asba ‘412, and further in view of Cavanagh et al., US 2017/0011213 A1 (hereinafter, “Cavanagh ‘213”).
As per claim 5: Khaund ’370 in view of Pangam ’195, and further in view of Asba ’412 discloses all limitations of claim 1, as stated above, from which claim 5 is dependent upon. Khaund ’370 in view of Pangam ’195, and further in view of Asba ’412 does not explicitly disclose the limitations of claim 5. Cavanagh ’213, however, discloses:
wherein the vault rotation user interface is a plugin (the cloud based active password manager employs a portable client device 110a plug-in or a software based client device 110b browser plug-in on the host computer 108, where the password manager device may be software-based modules installed on a host device; the user inputs information into registration fields using a graphical user interface (GUI) associated with the password manager, which may be a webpage hosted by the password manager system or a software application GUI installed on the user’s computer; the GUI presenting fields for the current user name, the current password, the password change URL, and the required fields for changing the password, together with input buttons [Cavanagh ‘213, ¶¶30, 49, 59-60; Fig.1]).
Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) and Cavanagh ‘213 are analogous art because they are from the same field of endeavor, namely that of automatically updating and managing authentication credentials used to access accounts within a networked computing environment. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) and Cavanagh ‘213 before them, to modify the system in Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) to include the teachings of Cavanagh ‘213, namely to provide the user interface of the system as a browser plug-in installed on the host computer of the user, as disclosed in Cavanagh ‘213. A motivation for doing so would be to provide the user with the ability to automatically update the passwords of each of their accounts, such that the user need not manually go and change the login credentials for all accounts, which is a time-intensive process that frustrates users (see Cavanagh ‘213, ¶¶4, 6).
As per claim 7: Khaund ‘370 in view of Pangam ‘195, and further in view of Asba ‘412 discloses all limitations of claim 1, as stated above, from which claim 7 is dependent upon. Khaund ‘370 in view of Pangam ‘195, and further in view of Asba ‘412 does not explicitly disclose the limitations of claim 7. Cavanagh ‘213, however, discloses:
wherein the vault data is accessed automatically by the vault rotation user interface (the client device 110b, which is provided as a browser plug-in on the host computer 108 and which presents the graphical user interface (GUI) associated with the password manager, is configured to detect when the user has accessed a given website which is in the list of websites to be managed by the user, and thereafter facilitates the automatic population of the user’s credentials, such as the login ID and the current password for the given website, to cause the user to be automatically logged into the given website; the host computer 108 uses the password manager device to auto-input the passwords of the user’s accounts and the user need not make any request to the client device in order to log into a given account [Cavanagh ‘213, ¶¶30, 49, 59; Fig.1]).
Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) and Cavanagh ‘213 are analogous art because they are from the same field of endeavor, namely that of automatically updating and managing authentication credentials used to access accounts within a networked computing environment. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) and Cavanagh ‘213 before them, to modify the system in Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) to include the teachings of Cavanagh ‘213, namely to configure the user interface of the system to retrieve the stored credential data automatically and without a request from the user, as disclosed in Cavanagh ‘213. A motivation for doing so would be to enable each user to efficiently and securely manage and update the credentials of their accounts, without the user being required to stay updated with news of data breaches and thereafter manually change the login credentials for all accounts stored in the password manager (see Cavanagh ‘213, ¶¶4, 6).
Claims 11-12 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Khaund ‘370, in view of Pangam ‘195, further in view of Asba ‘412, and further in view of Martin et al., US 2019/0050557 A1 (hereinafter, “Martin ‘557”).
As per claim 11: Khaund ‘370 in view of Pangam ‘195, and further in view of Asba ‘412 discloses all limitations of claim 1, as stated above, from which claim 11 is dependent upon. Khaund ‘370 in view of Pangam ‘195, and further in view of Asba ‘412 does not explicitly disclose the limitations of claim 11. Martin ‘557, however, discloses:
wherein executing the computer-readable code is configured to cause the at least one processing device to: identify each interaction at the vault rotation user interface and a vault identification user interface, wherein each interaction identified comprises a user account identifier associated with each interaction (all user interactions with the password manager 104 are logged, including the interactions of the first user, the second user and any administrative users; the password manager 104 logs an identification of data associated with a request for access to the first credential by any user, and where the data associated with such requests includes the time of logging, the time and date of the received request, the Internet Protocol (IP) address of the user machine 102 from which the password manager 104 receives the request, a user identifier associated with the requesting user, and the result of the request; the events that the password manager 104 tracks include, without limitation, sign on/off, add credential, use credential, change credential, delete credential, delegate credential, revoke delegation, grant privilege, and revoke privilege [Martin ‘557, ¶¶50, 53; Fig.1K, Fig.1L]); and
record each interaction in a user interaction database (the password manager 104 logs the identified data in an audit log, and further stores in a data structure, generated by and stored on the computing device 106 or in a database in communication with the computing device 106, an identification of a credential, an identification of an account accessed through the use of the identified credential, and an identification of the user that owns the credential, and, each time a request is received, an identification of the requesting user and an identification of the decision to grant or deny the request; the password manager 104 further includes functionality for analyzing one or more logs of a log database and generating a description of a user activity based upon the analysis [Martin ‘557, ¶¶50, 52-53]).
Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) and Martin ‘557 are analogous art because they are from the same field of endeavor, namely that of managing authentication credentials that are shared among a plurality of users, applications or services within a networked computing environment. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) and Martin ‘557 before them, to modify the system in Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) to include the teachings of Martin ‘557, namely to log each user interaction occurring at the user interfaces of the system, together with a user identifier associated with the user that performed the interaction, in an audit log maintained in a database, as disclosed in Martin ’557. A motivation for doing so would be to provide auditing functionality, which conventional password sharing systems do not typically provide, such that it can be tracked which user was using the credentials to access an account at any time, thereby simplifying administrative tasks and securing the account against improper usage by someone who had access to the shared account (see Martin ‘557, ¶¶6, 54).
As per claim 12: Khaund ‘370 in view of Pangam ‘195, and further in view of Asba ‘412, and further in view of Martin ‘557 discloses all limitations of claims 1 and 11, as stated above, from which claim 12 is dependent upon. Khaund ‘370 in view of Pangam ‘195, and further in view of Asba ‘412 does not explicitly disclose the limitations of claim 12. Martin ’557, however, discloses:
wherein executing the computer-readable code is configured to cause the at least one processing device to: determine each interaction is allowed or not allowed for each user account identifier, wherein the determination of each interaction is based on an associated security code for each user account identifier (the password manager 104 verifies ownership of the first credential by the second user and denies the request from the first user, and may apply additional security checks including two-factor authentication, submission of a time-stamped webcam photo of the user, submission of a signature by the user, or satisfaction of other criteria for authentication and/or authorization; the result of each request, whether the password manager 104 granted or denied authorization to access the credential, is determined with respect to the user identifier associated with the requesting user, which is the credential the user has to access the password manager 104, as opposed to the credential the user requests for accessing the application [Martin ‘557, ¶¶44-45, 50]);
flag, in an instance where an interaction of the each interaction is not allowed, the interaction (under the broadest reasonable interpretation, a “flag” may be interpreted as any stored indicator that designates a particular interaction as not being allowed (i.e., the stored identification of a decision to deny the request); the password manager 104 stores, in the data structure, an identification of the decision to grant or deny the request, and logs in the audit log the result of the request, namely whether authorization to access the credential was granted or denied [Martin ‘557, ¶¶50, 52]); and
transmit an alert interface component comprising the flag to a user device associated with the vault rotation user interface (the password manager 104 analyzes audit log content in order to determine whether to automatically generate and send alerts, and generates an alert and transmits the alert to the second user, to an administrative or management user, or both, and may further take an action in connection with the account, such as locking it out, marking it as expired, or changing the password [Martin ‘557, ¶¶39, 54]).
Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) and Martin ‘557 are analogous art because they are from the same field of endeavor, namely that of managing authentication credentials that are shared among a plurality of users, applications or services within a networked computing environment. For the reasons stated in claim 11, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) and Martin ‘557 before them, to modify the system in Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) to include the teachings of Martin ‘557.
As per claim 19: Claim 19 defines a computer program product that recites substantially similar subject matter as the system of claim 11. Specifically, claim 19 is directed to a computer program product comprising computer-readable program code portions which, when executed by a processing device, cause the processor to perform the functions performed by the system of claim 11. Thus, the rejection of claim 11 is equally applicable to claim 19.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Khaund ‘370, in view of Pangam ‘195, further in view of Asba ‘412, and further in view of Borochoff et al., US 2023/0122210 A1 (hereinafter, “Borochoff ‘210”).
As per claim 13: Khaund ‘370 in view of Pangam ‘195, and further in view of Asba ‘412 discloses all limitations of claim 1, as stated above, from which claim 13 is dependent upon. Khaund ‘370 does not explicitly disclose the limitations of claim 13. Pangam ‘195, however, discloses:
wherein the vault identifier is received at a vault identifier user interface, and wherein the vault identifier user interface is (at step 408, the user 111 provides functional account information to the password management application 106 via the UI 103 of the user device 102, where the UI 103 is generated by the user device 102 to render display elements including text input forms and interactive application windows, and where the functional account information received from the user device 102 includes, for each functional account to be enrolled, a functional account identifier for the functional account and an entity application identifier of the entity application to which the functional account is associated [Pangam ‘195, ¶¶33, 65; Fig.1, Fig.4]).
Khaund ‘370 and Pangam ‘195 are analogous art because they are from the same field of endeavor, namely that of automatically updating and managing authentication credentials used by applications and services within a networked computing environment. For the reasons stated in claim 6, prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Khaund ‘370 and Pangam ‘195 before them, to modify the system in Khaund ‘370 to include the teachings of Pangam ‘195.
As stated above, Khaund ‘370 in view of Pangam ‘195 does not explicitly disclose the limitation “… wherein the vault identifier user interface is a multi-user interface with the vault rotation user interface”, as recited in claim 13.
Borochoff ‘210, however, discloses:
… wherein the vault identifier user interface is a multi-user interface with the vault rotation user interface (under the broadest reasonable interpretation, a “multi-user interface” may be interpreted as two user interfaces that are coupled as one interactive system, such that each interaction at one user interface automatically and dynamically updates the other user interface; a resource dependency system that displays two dynamically interactive interfaces in a resource dependency user interface 100, namely a hierarchical resource repository 102 and a dependency graph user interface 104; user interactions on each interface can dynamically update either interface, such that a selection of a particular resource in the dependency graph user interface 104 causes the system to update the dependency graph user interface 104 to indicate the selection and also updates the hierarchical resource repository 102 to navigate to the appropriate folder corresponding to the stored location of the selected resource; a selection of a particular resource in the hierarchical resource repository 102 causes the system to update the hierarchical resource repository 102 to indicate the selection and also updates the dependency graph user interface 104 to display an updated graph, indicate the selection, and focus on the selected resource by zooming into a portion of the graph, where the graph user interface displays, for each displayed item, one or more of an identifier, a file name, a folder, or a folder path [Borochoff ‘210, ¶¶8, 19, 39; Fig.1]).
Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) and Borochoff ‘210 are analogous art because Borochoff ‘210 is reasonably pertinent to the particular problem with which the inventor was concerned, namely that of presenting to a user, by way of a user interface, the components of a networked computing environment that are dependent upon one another together with the identifiers of those components, such that the user may locate and act upon a particular component. Prior to the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) and Borochoff ‘210 before them, to modify the system in Khaund ‘370 (modified by Pangam ‘195 and Asba ‘412) to include the teachings of Borochoff ‘210, namely to couple the user interface at which the vault identifier is received with the vault rotation user interface, such that a selection made at either of those user interfaces automatically and dynamically updates the other, as disclosed in Borochoff ‘210. A motivation for doing so would be to allow large amounts of data to be automatically and dynamically calculated interactively in response to user inputs and to be efficiently and compactly presented to the user, thereby providing a user interface that is more efficient as compared to previous user interfaces in which data is not dynamically updated in response to interactive inputs (see Borochoff ‘210, ¶¶12-13).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Ness et al., US 20180123781 A1: Providing fault tolerant automatic secret rotation for secrets maintained in a secret distribution infrastructure. Rotate one or more secrets being served by the KMS system and provide other components of the secret distribution infrastructure with rotation information identifying the one or more secrets.
Cabrera et al., US 9467477 B2: Data security jurisdiction zones are identified and data security policy data for the data security jurisdiction zones is obtained. The data security policy data for the data security jurisdiction zones is then automatically analyzed to determine allowed secrets data with respect to each of the jurisdiction zones.
Koved et al., US 20170353450 A1: A decryption key corresponding to an authentication account of the user of a client device and authentication credential data obtained from the user of the client device is received during authentication. Encrypted authentication credential data corresponding to the user is decrypted.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALAN L KONG whose telephone number is (571)272-2646. The examiner can normally be reached Monday-Thursday 8:00am-4:30pm EST.
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, JUNG (JAY) KIM can be reached on (571)272-3804. 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.
/ALAN L KONG/
Examiner, Art Unit 2494
/JUNG W KIM/Supervisory Patent Examiner, Art Unit 2494
Prosecution Insights