DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to Amendment filed on 8/5/2026.
In instant Amendment, claims 1, 17 and 18 have been amended; claim 12 has been canceled; claims 19 and 20 have been newly added; claims 1, 17 and 18 are independent claims. Claims 1-11 and 13-20 have been examined and are pending. This Action is made Final.
Response to Arguments
Applicant's arguments filed 8/5/2026 have been fully considered but they are not persuasive.
Applicant Argues: Goldenberg describes a policy engine that receives an access request and generates a "context" for the requesting principal, from which an authorization engine computes a risk score and grants or denies access. Goldenberg derives that context from a justification such as an issue-tracking ticket, from the principal's existing permissions, group, or role, from the age of the user account, and from historical actions (Goldenberg , 1 [0038]-[0043], [0058]-[0064]). Goldenberg does not disclose an access graph, does not obtain the additional data by querying such a graph, and - critically - does not derive or represent the additional data as an access path comprising a series of hops between different systems.
Amended independent claim 1 now requires (i) accessing the additional data by querying an access graph that maps real users to user accounts and to externally-hosted resources, (ii) the additional data comprising at least one access path of the user to the target resource, defined as a series of hops between different systems, and (iii) analyzing the JIT access request in view of the at least one access path. Goldenberg 's principal-context/risk-score approach contains no graph, no access-path topology, and no multi-hop path analysis. Goldenberg therefore fails to disclose at least these limitations, and cannot anticipate amended claim 1. independent claims 17 and 18 recite corresponding limitations and are patentable over Goldenberg for the same reasons. The remaining rejected claims depend from claim I and are patentable at least by virtue of their dependency, as well as for the additional features they recite. Applicant reserves argument on the individua dependent claims and requests withdrawal of the§ 1 102(a)(2) rejection in its entirety.
With regard to the non-obviousness rejection, with claim 12 canceled and its subject matter incorporated into claim 1 in expanded form, and claims 9 and 15 depending from amended claim 1, these rejections are moot as applied. To the extent the references are considered against the amended claims, they do not cure the deficiencies of Goldenberg .
Khare was applied only for the general proposition of running a query on an access graph (former claim 12). Amended claim I requires substantially more: the additional data must comprise at least one access path defined as a series of hops between different systems, and the J1T access request must be analyzed in view of that access path. Khare's bare access-graph query does not teach or suggest deriving a multi-hop access path as the additional data for a JIT access decision, nor analyzing a JIT request in view of such a path; and neither Goldenberg nor Khare supplies this feature to the other.
... The amendments place the independent claims beyond the cited art by requiring an access-graph query yielding a multi-hop access path as the additional data, analyzed as part of the JIT access decision - features absent from Goldenberg alone and from Goldenberg in combination with Adam, Khare, or Shankar. Applicant submits that claims 1-20 are in condition for allowance and respectfully requests reconsideration and withdrawal of all rejections.
Examiner’s Response: In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references.
The examiner respectfully notes that Khare was shown to teach...accessing additional data associated with the identity of the user by querying an access graph that maps a plurality of nodes denoting real users to a plurality of user accounts... ([0045-[0046], as evidenced by Provisional application No. 63/571,988 – [0043]-[0044] - and [0083], as evidenced by Provisional application No. 63/571,988 – [0077] and [0113]), the access graph defining different permissions for the user accounts for accessing the different resources ([0083], as evidenced by Provisional application No. 63/571,988 – [0077] and [0098] as evidenced by Provisional application No. 63/571,988 – [0092]); ... analyzing the ... access request in view of the additional data; including in view of the at least one access path, to determine whether a target requirement is met ([0098] as evidenced by Provisional application No. 63/571,988 – [0092]). As noted in [0098] as evidenced by Provisional application No. 63/571,988 – [0092] - For example, the access graph 400 may include an identity node 410, one or more application account nodes 420, one or more user group nodes 430, one or more role nodes 440, and one or more data resource nodes 450. Each type of nodes may include its own set of attributes. For illustration, not all values of the attributes are shown in FIG. 4A. The data management server 130 may identify any data permission traversal path that traverses between an identity node 410 (or an application account node 420) and a data resource node 450 to identify data permission between a named entity and a data resource. Thus, as construed the additional data can include one or more application account nodes 420, one or more user group nodes 430, one or more role nodes 440, and one or more data resource nodes 450 within the data permission traversal path, thus having different permissions for accessing the different resources. The examiner notes that Lim is shown to teach features of at least one access path defined as a series of hops between different systems, and the J1T access request must be analyzed in view of that access path. Therefore, the examiner finds this argument moot in view of new grounds of rejection.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-8, 10-11, 13-14, and 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Goldenberg et al. (US 2026/0050680 A1) in view of Khare et al. (US 2025/0307361 A1) as evidenced by Provisional application No. 63/571,988 filed on March 29, 2024 and Lim et al. (US 2025/0310329 A1).
Regarding Claim 1;
Goldenberg discloses a computer implemented method of managing adaptive just-in-time (JIT) access requests (FIG. 1 and FIG. 2 and [0020] - FIG. 1 is an example schematic diagram of a computing environment utilizing a policy engine for just in time access management, utilized to describe an embodiment.), comprising:
receiving a JIT access request (FIG. 2 and [0033]-[0034] - In an embodiment, a just-in-time access refers to providing an access, a permission, etc., only when it is needed and when it is deemed to be required... In an embodiment, a policy engine 150 is configured to receive a request to access a resource), the JIT access request including an identity of a user making the request ([0034] - For example, in an embodiment, the request includes an identifier of a principal (e.g., a user account, a service account, a role, a user group, a combination thereof, and the like), and a target resource to which access is requested ([0035] - In some embodiments, the request further includes an identifier of the resource);
automatically accessing additional data associated with the identity of the user... ([0038]-[0039] - In an embodiment, the context generator 210 is configured to generate a context based on the received request... In certain embodiments, the context generator 210 is configured to generate a context based on a justification. For example, in an embodiment, a justification is generated by extracting data related to the resource, the action, the principal, a combination thereof, and the like);
automatically analyzing the JIT access request in view of the additional data ([0044] - In an embodiment, an authorization engine 220 is configured to generate requests for authorization. For example, in an embodiment, the authorization engine 220 is configured to determine, based on the generated context from the context generator 210, what permission, if at all, to grant the requesting principal);
in response to the analysis meeting [a] target requirement ([0044]), automatically granting temporary access to the user to access the target resource for a defined time interval ([0045] - According to an embodiment, the authorization engine 220 is further configured to generate the request for authorization based on a time value, an action count, another permission, a combination thereof, and the like. For example, in an embodiment, a time value is a time limit, a time window, etc. In some embodiments, an action count is a certain predetermined number of actions the principal is authorized to perform before such actions are blocked, require reauthorization, etc.); and
automatically revoking the temporary access in response to expiration of the defined time interval ([0010] - generating a time-limited access permission and [0045] - For example, in an embodiment, a time value is a time limit, a time window, etc. In some embodiments, an action count is a certain predetermined number of actions the principal is authorized to perform before such actions are blocked, require reauthorization, etc.).
Goldenberg fails to explicitly disclose:
...accessing additional data associated with the identity of the user by querying an access graph that maps a plurality of nodes denoting real users to a plurality of user accounts and to a plurality of resources hosted by a plurality of service computing environments external to a target computing environment accessed by the user accounts, the access graph defining different permissions for the user accounts for accessing the different resources, wherein the additional data comprises at least one access path of the identity of the user to the target resource, each access path being defined as a series of hops between different systems;
... analyzing the ... access request in view of the additional data; including in view of the at least one access path, to determine whether a target requirement is met.
However, in an analogous art, Khare teaches
...accessing additional data associated with the identity of the user by querying an access graph that maps a plurality of nodes denoting real users to a plurality of user accounts... ([0045-[0046], as evidenced by Provisional application No. 63/571,988 – [0043]-[0044] - The data management server 130 may also include one or more virtualization instances such as a container, a virtual machine, a virtual private server, a virtual kernel, or another suitable virtualization instance. The data management server 130 may provide organizations 110 with various data management services as a form of cloud-based software, such as software as a service (SaaS), through the network 160 and [0083], as evidenced by Provisional application No. 63/571,988 – [0077] - In some embodiments, the object model for the data objects 240 according to the data schema 232 may have multiple entities. Examples of the objects include identity, applicationAccount, userGroup, resource, accessTo, etc. Each object may be a type of node that may be used by the data management server 130 in generating a data access graph. In some embodiments, the various types of objects may have one or more relationships related to other types of objects or the same types of objects (e.g., sub-types). For example, the identity object may be derived from the identity system and represent a named entity. Each identity can have one or more applicationAccounts. ApplicationAccount can have membership to one or more userGroup and/or roles. UserGroup can be nested. UserGroup can have child userGroup. A userGroup can be a member of one or more roles. Roles can be nested. Roles can have child roles. Roles can have permission to one or more data resources. The relationship between an applicationAccount and a resource may be specified by an accessTo data object that specifies the role that has access permission to the resource and [0113], as evidenced by Provisional application No. 63/571,988 - [0108] - The data management server 130 may provide customers with a data query feature for querying the data arranged in the data model in the data store 242. The data query feature may take any suitable form of a query system 270 such as an API query system. An accessGraph may be the root type that contains supported query types. A query can request a single object (e.g., account, group, resource, role) or a list of objects (accounts, resources, risks). In some embodiments, the query system of the data management server 130 may support at least a query to an access graph or query to a specific node object), the access graph defining different permissions for the user accounts for accessing the different resources ([0083], as evidenced by Provisional application No. 63/571,988 – [0077] - In some embodiments, the object model for the data objects 240 according to the data schema 232 may have multiple entities. Examples of the objects include identity, applicationAccount, userGroup, resource, accessTo, etc. Each object may be a type of node that may be used by the data management server 130 in generating a data access graph. In some embodiments, the various types of objects may have one or more relationships related to other types of objects or the same types of objects (e.g., sub-types). For example, the identity object may be derived from the identity system and represent a named entity. Each identity can have one or more applicationAccounts. ApplicationAccount can have membership to one or more userGroup and/or roles. UserGroup can be nested. UserGroup can have child userGroup. A userGroup can be a member of one or more roles. Roles can be nested. Roles can have child roles. Roles can have permission to one or more data resources. The relationship between an applicationAccount and a resource may be specified by an accessTo data object that specifies the role that has access permission to the resource and [0098] as evidenced by Provisional application No. 63/571,988 – [0092] - For example, the access graph 400 may include an identity node 410, one or more application account nodes 420, one or more user group nodes 430, one or more role nodes 440, and one or more data resource nodes 450. Each type of nodes may include its own set of attributes. For illustration, not all values of the attributes are shown in FIG. 4A. The data management server 130 may identify any data permission traversal path that traverses between an identity node 410 (or an application account node 420) and a data resource node 450 to identify data permission between a named entity and a data resource. By way of example, the identity node 410 may have different application accounts for SaaS platform A and SaaS platform B (each may be an example of a workspace data source 120).
... analyzing the ... access request in view of the additional data; including in view of the at least one access path, to determine whether a target requirement is met ([0098] as evidenced by Provisional application No. 63/571,988 – [0092] - For example, the access graph 400 may include an identity node 410, one or more application account nodes 420, one or more user group nodes 430, one or more role nodes 440, and one or more data resource nodes 450. Each type of nodes may include its own set of attributes. For illustration, not all values of the attributes are shown in FIG. 4A. The data management server 130 may identify any data permission traversal path that traverses between an identity node 410 (or an application account node 420) and a data resource node 450 to identify data permission between a named entity and a data resource. By way of example, the identity node 410 may have different application accounts for SaaS platform A and SaaS platform B (each may be an example of a workspace data source 120).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Khare to the JIT access request of Goldenberg to include automatically accessing additional data associated with the identity of the user by querying an access graph that maps a plurality of nodes denoting real users to a plurality of user accounts and to a plurality of resources hosted by a plurality of service computing environments external to a target computing environment accessed by the user accounts, the access graph defining different permissions for the user accounts for accessing the different resources, wherein the additional data comprises at least one access path of the identity of the user to the target resource, each access path being defined as a series of hops between different systems; ... analyzing the ... access request in view of the additional data; including in view of the at least one access path, to determine whether a target requirement is met.
One would have been motivated to combine the teachings of Khare to Goldenberg to do so as it provides / allows efficient granting and revoking data access privilege (Khar, [0002]-[0003]).
Further in an analogous art, Lim teaches
...accessing additional data associated with the identity of the user... and to a plurality of resources hosted by a plurality of service computing environments external to a target computing environment accessed by the user accounts..., wherein the additional data comprises at least one access path of the identity of the user to the target resource, each access path being defined as a series of hops between different systems (([0013] - In some implementations, as described in further detail herein, the zero trust system may be configured to verify each user and machine entity at each leg or segment of an authentication and authorization context (e.g., according to multiple factors, which may include an identity, a location, a device, a service, a workload, a data classification, and/or an anomaly, among other examples) and [0028] - In some implementations, as described herein, one facet of the zero trust security model is that authentication and authorization is performed for each machine or non-machine entity attempting to access an IT resource at each leg or hop in an access path);
... analyzing the ... access request in view of the additional data; including in view of the at least one access path, to determine whether a target requirement is met ([0013] - In some implementations, as described in further detail herein, the zero trust system may be configured to verify each user and machine entity at each leg or segment of an authentication and authorization context (e.g., according to multiple factors, which may include an identity, a location, a device, a service, a workload, a data classification, and/or an anomaly, among other examples) and [0028] - In some implementations, as described herein, one facet of the zero trust security model is that authentication and authorization is performed for each machine or non-machine entity attempting to access an IT resource at each leg or hop in an access path).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of LIM to the JIT access request of Goldenberg and Khare to include ...accessing additional data associated with the identity of the user... and to a plurality of resources hosted by a plurality of service computing environments external to a target computing environment accessed by the user accounts..., wherein the additional data comprises at least one access path of the identity of the user to the target resource, each access path being defined as a series of hops between different systems; ... analyzing the ... access request in view of the additional data; including in view of the at least one access path, to determine whether a target requirement is met
One would have been motivated to combine the teachings of Lim to Goldenberg and Khare to do so as it provides / allows strict identity verification for every user and every device attempting to access a protected IT resource, regardless of whether a user or device is located within or outside a perimeter of a protected IT environment (Lim, [0012]).
Regarding Claim 2;
Goldenberg in view of Khare and Lim disclose the method of claim 1.
Goldenberg further discloses wherein the JIT access request further includes a requested permission level, and the analysis is performed in view of the requested permission level ([0026] - In an embodiment, an authorizing principal 135 is a principal of the computing environment 110 which includes a higher level of permission than the principal 130 and [0041] - In some embodiments, the request includes a permission which is excessive based on the justification and [0044]).
Regarding Claim 3;
Goldenberg in view of Khare and Lim disclose the method of claim 1.
Goldenberg further discloses wherein the temporary access is granted without requiring a password for accessing the target resource by the user within the defined time interval ([0067]-[068] - In an embodiment, granting access permission includes configuring an identity and access management (IAM) service with a policy, a rule, a condition, and the like, based on the determined access permission (i.e., as noted without requiring a password). In some embodiments, the access permission is granted for a limited period of time).
Regarding Claim 4;
Goldenberg in view of Khare and Lim disclose the method of claim 1.
Goldenberg further discloses wherein the analysis is performed by applying a set of rules defining a risk policy, wherein the target requirement is met when the set of rules is met ([0046] - For example, in some embodiments, the authorization engine is configured to apply a policy, a rule, a heuristic, a combination thereof, and the like and [0064]-[0065] - For example, in an embodiment, a risk based on the principal is determined based on the age of the user account, whether the user account initiated such actions in the past, whether such actions were authorized in the past with respect to the user account, whether such actions were denied in the past with respect to the user account, whether the permission allows to initiate more actions other than what is required (e.g., admin permission vs. role permission), a combination thereof, and the like and [0070] - According to some embodiments, the permission is granted in response to determining that a risk score, for example determined based on the generated context, is below a predetermined threshold).
Regarding Claim 5;
Goldenberg in view of Khare and Lim disclose the method of claim 1.
Goldenberg further discloses wherein the analysis is performed by computing a score indicating likelihood of a security threat, and target requirement is met when the score is less than a threshold indicating a tolerated security risk ([0070] - According to some embodiments, the permission is granted in response to determining that a risk score, for example determined based on the generated context, is below a predetermined threshold).
Regarding Claim 6;
Goldenberg in view of Khare and Lim disclose the method of claim 1.
Goldenberg further discloses wherein the analysis is performed by identifying at least one contradiction between the additional data and the JIT access request, and the target requirement is met when there is no contradiction ([0070] - According to some embodiments, the permission is granted in response to determining that a risk score, for example determined based on the generated context, is below a predetermined threshold. In an embodiment, where the risk score is above a predetermined level but below a second predetermined level, a secondary authentication is performed).
Regarding Claim 7;
Goldenberg in view of Khare and Lim disclose the method of claim 1.
Goldenberg further discloses wherein the user is a member of a group that includes other users, wherein the temporary access is granted to the user and not granted to the other users of the group ([0024] and [0053] - In an embodiment, the request includes an identifier of a principal, such as a username of a user account and [0057] - In some embodiments, a permission is granted to an individual user).
Regarding Claim 8;
Goldenberg in view of Khare and Lim disclose the method of claim 1.
Goldenberg further discloses wherein the JIT access request further includes a reason for the request to access the target resource, and the analysis is performed according to the reason ([0050] - In an embodiment, the request includes an identifier of a principal, an identifier of a resource, and an action (i.e., as noted a reason)).
Regarding Claim 10;
Goldenberg in view of Khare and Lim disclose the method of claim 1.
Goldenberg further discloses wherein in response to the analysis not meeting the target requirement, a message indicating the JIT access request is sent to another computer for manual review and approval ([0070-[0071] - According to some embodiments, the permission is granted in response to determining that a risk score, for example determined based on the generated context, is below a predetermined threshold. In an embodiment, where the risk score is above a predetermined level but below a second predetermined level, a secondary authentication is performed. For example, in an embodiment, a secondary authentication includes a request for multifactor authentication (MFA), a request to authenticate with an authorizing principal (e.g., an administrator account), a combination thereof, and the like).
Regarding Claim 11;
Goldenberg in view of Khare and Lim disclose the method of claim 1.
Goldenberg further discloses wherein the additional data includes at least one of: additional data about the requesting user, additional data about the target resource, existing access privileges of the user to other resources, role and/or position within an organization, denial or approval of historical access requests, time and/or data of the JIT access request, and geographical location from which the JIT access request is made ([0038]-[0039] - In an embodiment, the context generator 210 is configured to generate a context based on the received request... In certain embodiments, the context generator 210 is configured to generate a context based on a justification. For example, in an embodiment, a justification is generated by extracting data related to the resource, the action, the principal, a combination thereof, and the like).
Regarding Claim 13;
Goldenberg in view of Khare and Lim disclose the method of claim 1.
Goldenberg further discloses wherein the target resources is hosted by an external service computing environment, and the JIT access request is for accessing the external service computing environment via a target service computing environment accessed by the user via a client ([0021]-[0022] and [0035] - In some embodiments, the request further includes an identifier of the resource, an IP address of the resource, an identifier of the resource group (e.g., software container identifier, auto-scaling group identifier, etc.), an identifier of a virtual private cloud (VPC) in which the resource is deployed, an identifier of a virtual private network (VPN) associated with the resource, an identifier of a virtual network (VNet) associated with the resource, a combination thereof, and the like).
Regarding Claim 14;
Goldenberg in view of Khare and Lim disclose the method of claim 1.
Goldenberg further discloses further comprising: in response to the analysis meeting the target requirement, sending a message to a target service environment hosting the target resource, to set permission granting access to the user to access the target resource ([0067] - At S360, an access permission is granted to the principal. In an embodiment, granting access permission includes configuring an identity and access management (IAM) service with a policy, a rule, a condition, and the like, based on the determined access permission and [0079] - The network interface 440 is configured to provide the policy engine 150 with communication with, for example, the computing environment 110, the IAM service 140, the authorizing principal 135, and the like, according to an embodiment)
Regarding Claim 16;
Goldenberg in view of Khare and Lim disclose the method of claim 1.
Goldenberg further discloses wherein the target resource includes at least one of: a service and/or application provided by an external service computing environment, a file hosted by the external service computing environment, and actions to be performed by the external service computing environment ([0021]-[0022] and [0035] - In some embodiments, the request further includes an identifier of the resource, an IP address of the resource, an identifier of the resource group (e.g., software container identifier, auto-scaling group identifier, etc.), an identifier of a virtual private cloud (VPC) in which the resource is deployed, an identifier of a virtual private network (VPN) associated with the resource, an identifier of a virtual network (VNet) associated with the resource, a combination thereof, and the like and ([0050] - In an embodiment, the request includes an identifier of a principal, an identifier of a resource, and an action (i.e., as noted a reason)).
Regarding Claim(s) 17; claim(s) 17 is/are directed to a/an system associated with the method claimed in claim(s) 1. Claim(s) 17 is/are similar in scope to claim(s) 1, and is/are therefore rejected under similar rationale.
Regarding Claim(s) 18; claim(s) 18 is/are directed to a/an medium associated with the method claimed in claim(s) 1. Claim(s) 18 is/are similar in scope to claim(s) 1, and is/are therefore rejected under similar rationale.
Regarding Claim 19;
Goldenberg in view of Khare and Lim disclose the method of claim 1.
Khare further teaches wherein the at least one access path comprises an indirect access path in which a first user account accesses a first resource, obtains a second user account of the first resource, and accesses a second target resource using the second user account ([0028], as evidenced by Provisional application No. 63/571,988 – [0079] - An applicationAccount node may be used to uniquely identify an account in a software application such as a SaaS platform. A named entity identified by an identity node can have multiple applicationAccounts in different software applications. For example, an employee can have a first application account in SaaS platform A and a second application account in SaaS platform B).
Similar rationale and motivation is noted for the combination of Khare to Goldenberg in view of Khare and Lim, as per claim 1, above.
Regarding Claim 20;
Goldenberg in view of Khare and Lim e discloses the method of claim 1.
Lim further teaches wherein analyzing the JIT access request comprises analyzing the at least one access path associated with granting the temporary access to identify whether the at least one access path indicates a security risk, and the target requirement is met when the at least one access path does not indicate the security risk ([0013] - Furthermore, when a machine or non-machine entity is authenticated and authorized to access an IT resource, the zero trust system may grant the access using least privileges (e.g., no privileges or just-enough-access (JEA)), where the requesting entity is only granted as much access as needed to access the IT resource. In this way, the least privileges or JEA techniques may minimize exposure of sensitive IT resources or data. In addition, the zero trust system may provide just-in-time (JIT) access, which may grant an authenticated and authorized entity temporary and on-demand permissions to access an IT resource. In this way, a user or device that may not typically need to use certain IT resources can receive timely access to the IT resources when needed, but access is always temporary and granted only at the time when the user or device attempts to access the target IT resource).
Similar rationale and motivation is noted for the combination of Lim to Goldenberg in view of Khare and Lim, as per claim 1, above.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Goldenberg et al. (US 2026/0050680 A1) in view of Khare et al. (US 2025/0307361 A1) as evidenced by Provisional application No. 63/571,988 filed on March 29, 2024 and Lim et al. (US 2025/0310329 A1) and further in view of Adam et al. (US 2024/0291822 A1).
Regarding Claim 9;
Goldenberg in view of Khare and Lim disclose the method of claim 1.
Goldenberg in view of Khare and Lim fails to explicitly disclose wherein the JIT access request further includes the time interval for the temporary access to the target resource, and the analysis is performed according to the requested time interval.
However, in an analogous art, Adam further teaches wherein the JIT access request further includes the time interval for the temporary access to the target resource, and the analysis is performed according to the requested time interval ([0045] - The system 100 may allow just-in-time access for a user to one or more computer resources. “Just-in-time” (or JIT) may include substantially just-in-time events or provision (as of computer resources) as they are needed, such as by a user, by the enterprise, etc., which may include a delay, such as to the user or the enterprise, between requesting of the access and enabling of access to the computer resource and [0059] - The request interface 400 may include a text box 410, drop down menu, or other input element, which may allow a user to select a time duration for requested access to the computer resource. The options may be time intervals, such as 30 minutes, 1 hour, several hours, etc., which may vary depending on the computer resource. The time intervals may be designed to accommodate an average task which may be performed by a user with the computer resource. Examples of the time intervals are provided in FIG. 5).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Adam to the JIT access request of Goldenberg in view of Khare and Lim to include wherein the JIT access request further includes the time interval for the temporary access to the target resource, and the analysis is performed according to the requested time interval
One would have been motivated to combine the teachings of Adam to Goldenberg in view of Khare and Lim to do so as it provides / allows increased security [by] enabling of access as needed and as-long-as needed (Adam, [0029]).
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Goldenberg et al. (US 2026/0050680 A1) in view of Khare et al. (US 2025/0307361 A1) as evidenced by Provisional application No. 63/571,988 filed on March 29, 2024 and Lim et al. (US 2025/0310329 A1) and further in view of Shankar (US 2020/0412741 A1).
Regarding Claim 15;
Goldenberg in view of Khare and Lim discloses the method of claim 1.
Goldenberg in view of Khare and Lim fails to explicitly disclose further comprising: in response to revoking the access after the defined time interval expired, performing a clean-up on the target service environment hosing the target resource for ensuring there are no left-overs from the temporary access.
However, in an analogous art, Shankar further teaches comprising: in response to revoking the access after the defined time interval expired, performing a clean-up on the target service environment hosing the target resource for ensuring there are no left-overs from the temporary access ([0016] and [0044] - If the request is approved, the security center can automatically configure a network security group (e.g., NSG) to allow inbound traffic to a selected port and requested source IP addresses or ranges, for the amount of time that was specified. After the time has expired, the security center restores the NSGs to previous states, while keeping the connections that are already established uninterrupted.).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Shankar to the JIT access request of Goldenberg in view of Khare and Lim to include further comprising: in response to revoking the access after the defined time interval expired, performing a clean-up on the target service environment hosing the target resource for ensuring there are no left-overs from the temporary access
One would have been motivated to combine the teachings of Shankar to Goldenberg in view of Khare and Lim to do so as it provides / allows improving resource policy management in an access management system of a distributed computing environment (“computing environment”) (Shankar, [0005]).
Conclusion
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 KARI L SCHMIDT whose telephone number is (571)270-1385. The examiner can normally be reached Monday-Friday 10am - 6pm (MDT).
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, Luu Pham can be reached at (571)270-5002. 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.
/KARI L SCHMIDT/Primary Examiner, Art Unit 2439
Prosecution Insights