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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 04 May 2026 has been entered.
Response to Amendment
Applicant’s amendment filed 04 May 2026 amends claims 1, 2, 4-6, 9, 10, 12-14, 17, 18, and 20-22 are amended. Applicant’s amendment has been fully considered and entered.
Response to Arguments
Applicant argues on page 12 of the response, “…claim 1 requires that the access policy for a cloud infrastructure resource of the cloud provider is defined by the customer to allow the customer to control access to the cloud infrastructure resource by the operator employee of the cloud provider.” This argument has been fully considered and is persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground of rejection is made in view of El Kalam, “Organization based access control”, published 2003.
Applicant's remaining arguments do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the references cited or the objections made. Further, they do not show how the amendments avoid such references or rejections. Specifically, Applicant references the Final Action’s reliance on “internal administrators 108” and such references failing to disclose multiple limitations of claim 1. However, Applicant has failed to clearly point out which limitations are not believed to be taught by Dani.
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.
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-24 are rejected under 35 U.S.C. 103 as being unpatentable over Dani, U.S. Publication No. 2016/0277411, in view of El Kalam, “Organization based access control”, published 2003. Referring to claim 1, Dani discloses access control system for cloud-based services ([0016]-[0017]) that include a set of permission policies that are implemented to determine access to requested services ([0021]) that are hosted by cloud service providers for client organizations ([0016]: client organizations are cloud computing customers), which meets the limitation of configuring a customer access control mechanism for the cloud infrastructure resource of the cloud provider that is used by the customer of the cloud provider, wherein the customer access control mechanism comprises the access policy for processing an access request from the operator employee of the cloud provider to allow the operator employee cloud provider to access the cloud infrastructure resource used by the customer. The access control request corresponds with a request that requires approval from one or more internal administrators ([0021 & [0034]-[0035]), which meets the limitation of the access request corresponds to an access type that requires that the access request be approved by the customer before the operator employee of the cloud provider is allowed to access the cloud infrastructure resource. The permission policy includes criterion that identify the ability to automatically approve access control requests ([0029]-[0030]: criterion reads on the claimed keyword; automatic approval reads on the claimed overriding a requirement of the customer approval), which meets the limitation of the access policy comprises a keyword that corresponds to one or more conditions for overriding the requirement that the customer approve of the access request, and automatically permitting the operator employee of the cloud provider to access the cloud infrastructure resource used by the customer according to the access policy allowing for overriding of the requirement that the access request of the operator employee be approved by the customer. Automatic approval of the access control requests based on the criterion in the permission policy prevents authorization steps 316-330 from being performed (Figure 3: these authorization steps represent the claimed check that is not obtained), which meets the limitation of wherein approval of the access request is not obtained from the customer when overriding the customer approval requirement and automatically permitted the operator employee of the cloud provider to access the cloud infrastructure resource used by the customer.
Dani does not specify that the permission policies are defined by the client organizations. El Kalam discloses permission policies defined by the organizations (Page 2, right column, last paragraph & Page 5, left column, Section 4.6: every context can be seen as a ternary relation between subjects, objects and actions defined within such or such some organization; Examiner notes that the name “operator employee” is just the name of a requester and such a name represents non-functional descriptive material that is not given patentable weight. See MPEP 2111.04-2111.05), which meets the limitation of defining an access policy for a cloud infrastructure resource of a cloud provider wherein the access policy is defined by a customer of the cloud provider to allow the customer to control access to the cloud infrastructure resource by an operator employee of the cloud provider. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the permission policies of Dani to have been defined by the client organization in order enable a given organization to specify the permissions granted in a given context as suggested by El Kalam (Page 6, left column, Section 4.8).
Referring to claim 2, Dani discloses that the permission policy includes criterion that identify the ability to automatically approve access control requests ([0029]-[0030]: criterion include user group criterion, flag criterion, action scope criterion, and schedule criterion; these criterion reads on the claimed keyword comprising text because these criterion from the permission policy would be textual and “indicative” of the ability to automatically approve requests, which would correspond to the claimed “override”), which meets the limitation of wherein the keyword comprises text included within the defined access policy and is indicative of an override condition that is checked to determine whether the access by the operator employee of the cloud provider is permitted without the requirement that the customer approve of the access request.
Referring to claim 3, Dani discloses that the request includes the identity of the requesting operator ([0019]) such that the corresponding user group of the requesting operator is checked against the permission policy user group criterion that dictates a user group whose access control requests can be automatically approved ([0029]-[0030]), which meets the limitation of wherein the access request comprises information evaluated for determining whether the customer approval override condition of the access policy is satisfied.
Referring to claim 4, Dani discloses that the access control request that identify an action that the operator wants to perform ([0019]), which meets the limitation of wherein the information of the access request includes at least one of a scope of access, a category of access, a reason for access.
Referring to claims 5, 6, Dani discloses that the permission policy includes criterion that identify the ability to automatically approve access control requests ([0029]-[0030]: criterion corresponding with request data can be considered a security incident that is checked against security ticketing), which meets the limitation of wherein the override condition of the access policy corresponds to a security incident, the security incident is checked against security ticketing.
Referring to claim 7, Dani discloses that the requested action can include performing a debugging trace ([0031]), which meets the limitation of wherein the cloud provider operator access that is performed without checking for the customer approval comprises a diagnosis operation.
Referring to claim 8, Dani discloses that the request includes the identity of the requesting operator ([0019]) such that the corresponding user group of the requesting operator is checked against the permission policy user group criterion that dictates a user group whose access control requests can be automatically approved ([0029]-[0030]). Automatic approval of the access control requests based on the criterion in the permission policy prevents authorization steps 316-330 from being performed (Figure 3). The user assignment to the particular user group can be temporary ([0025]), therefore, any further access control requests received from the operator after expiration of this temporary time period would require the additional authorization steps 316-330 (Figure 3), which meets the limitation of wherein multiple override requests are subject to an additional approval process.
Referring to claim 9, Dani discloses access control system for cloud-based services ([0016]-[0017]) that include a set of permission policies that are implemented to determine access to requested services ([0021]) that are hosted by cloud service providers for client organizations ([0016]: client organizations are cloud computing customers), which meets the limitation of configuring a customer access control mechanism for the cloud infrastructure resource of the cloud provider that is used by the customer of the cloud provider, wherein the customer access control mechanism comprises the access policy for processing an access request from the operator employee of the cloud provider to allow the operator employee cloud provider to access the cloud infrastructure resource used by the customer. The access control request corresponds with a request that requires approval from one or more internal administrators ([0021 & [0034]-[0035]), which meets the limitation of the access request corresponds to an access type that requires that the access request be approved by the customer before the operator employee of the cloud provider is allowed to access the cloud infrastructure resource. The permission policy includes criterion that identify the ability to automatically approve access control requests ([0029]-[0030]: criterion reads on the claimed keyword; automatic approval reads on the claimed overriding a requirement of the customer approval), which meets the limitation of wherein the access policy comprises a keyword that corresponds to one or more conditions for overriding the requirement that the customer approve of the access request, and automatically permitting the operator employee of the cloud provider to access the cloud infrastructure resource used by the customer according to the access policy allowing for overriding of the requirement that the access request of the operator employee be approved by the customer. Automatic approval of the access control requests based on the criterion in the permission policy prevents authorization steps 316-330 from being performed (Figure 3: these authorization steps represent the claimed check that is not obtained), which meets the limitation of wherein approval of the access request is not obtained from the customer when overriding the customer approval requirement and automatically permitted the operator employee of the cloud provider to access the cloud infrastructure resource used by the customer..
Dani does not specify that the permission policies are defined by the client organizations. El Kalam discloses permission policies defined by the organizations (Page 2, right column, last paragraph & Page 5, left column, Section 4.6: every context can be seen as a ternary relation between subjects, objects and actions defined within such or such some organization; Examiner notes that the name “operator employee” is just the name of a requester and such a name represents non-functional descriptive material that is not given patentable weight. See MPEP 2111.04-2111.05), which meets the limitation of defining an access policy for a cloud infrastructure resource of a cloud provider, wherein the access policy is defined by a customer of the cloud provider to allow the customer to control access to the cloud infrastructure resource by an operator employee of the cloud provider. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the permission policies of Dani to have been defined by the client organization in order enable a given organization to specify the permissions granted in a given context as suggested by El Kalam (Page 6, left column, Section 4.8).
Referring to claim 10, Dani discloses that the permission policy includes criterion that identify the ability to automatically approve access control requests ([0029]-[0030]: criterion include user group criterion, flag criterion, action scope criterion, and schedule criterion; these criterion reads on the claimed keyword comprising text because these criterion from the permission policy would be textual and “indicative” of the ability to automatically approve requests, which would correspond to the claimed “override”), which meets the limitation of wherein the keyword comprises text included within the defined access policy and is indicative of an override condition that is checked to determine whether the access by the operator employee of the cloud provider is permitted without the requirement that the customer approve of the access request.
Referring to claim 11, Dani discloses that the request includes the identity of the requesting operator ([0019]) such that the corresponding user group of the requesting operator is checked against the permission policy user group criterion that dictates a user group whose access control requests can be automatically approved ([0029]-[0030]), which meets the limitation of wherein the access request comprises information evaluated for determining whether the customer approval override condition of the access policy is satisfied.
Referring to claim 12, Dani discloses that the access control request that identify an action that the operator wants to perform ([0019]), which meets the limitation of wherein the information of the access request includes at least one of a scope of access, a category of access, a reason for access.
Referring to claims 13, 14, Dani discloses that the permission policy includes criterion that identify the ability to automatically approve access control requests ([0029]-[0030]: criterion corresponding with request data can be considered a security incident that is checked against security ticketing), which meets the limitation of wherein the override condition of the access policy corresponds to a security incident, the security incident is checked against security ticketing.
Referring to claim 15, Dani discloses that the requested action can include performing a debugging trace ([0031]), which meets the limitation of wherein the cloud provider operator access that is performed without checking for the customer approval comprises a diagnosis operation.
Referring to claim 16, Dani discloses that the request includes the identity of the requesting operator ([0019]) such that the corresponding user group of the requesting operator is checked against the permission policy user group criterion that dictates a user group whose access control requests can be automatically approved ([0029]-[0030]). Automatic approval of the access control requests based on the criterion in the permission policy prevents authorization steps 316-330 from being performed (Figure 3). The user assignment to the particular user group can be temporary ([0025]), therefore, any further access control requests received from the operator after expiration of this temporary time period would require the additional authorization steps 316-330 (Figure 3), which meets the limitation of wherein multiple override requests are subject to an additional approval process.
Referring to claim 17, Dani discloses access control system that includes a processor (Figure 4, element 402) and a memory storing instructions (Figure 4, element 404) for cloud-based services ([0016]-[0017]) that include a set of permission policies that are implemented to determine access to requested services ([0021]) that are hosted by cloud service providers for client organizations ([0016]: client organizations are cloud computing customers), which meets the limitation of a system comprising a processor, a memory for holding programmable code, and wherein the programmable code includes instructions executable by the processor for configuring a customer access control mechanism for the cloud infrastructure resource of the cloud provider that is used by the customer of the cloud provider, wherein the customer access control mechanism comprises the access policy for processing an access request from the operator employee of the cloud provider to allow the operator employee cloud provider to access the cloud infrastructure resource used by the customer. The access control request corresponds with a request that requires approval from one or more internal administrators ([0021 & [0034]-[0035]), which meets the limitation of the access request corresponds to an access type that requires that the access request be approved by the customer before the operator employee of the cloud provider is allowed to access the cloud infrastructure resource. The permission policy includes criterion that identify the ability to automatically approve access control requests ([0029]-[0030]: criterion reads on the claimed keyword; automatic approval reads on the claimed overriding a requirement of the customer approval), which meets the limitation of wherein the access policy comprises a keyword that corresponds to one or more conditions for overriding the requirement that the customer approve of the access request, and automatically permitting the operator employee of the cloud provider to access the cloud infrastructure resource used by the customer according to the access policy allowing for overriding of the requirement that the access request of the operator employee be approved by the customer. Automatic approval of the access control requests based on the criterion in the permission policy prevents authorization steps 316-330 from being performed (Figure 3: these authorization steps represent the claimed check that is not obtained), which meets the limitation of wherein approval of the access request is not obtained from the customer when overriding the customer approval requirement and automatically permitted the operator employee of the cloud provider to access the cloud infrastructure resource used by the customer.
Dani does not specify that the permission policies are defined by the client organizations. El Kalam discloses permission policies defined by the organizations (Page 2, right column, last paragraph & Page 5, left column, Section 4.6: every context can be seen as a ternary relation between subjects, objects and actions defined within such or such some organization; Examiner notes that the name “operator employee” is just the name of a requester and such a name represents non-functional descriptive material that is not given patentable weight. See MPEP 2111.04-2111.05), which meets the limitation of defining an access policy for a cloud infrastructure resource of a cloud provider, wherein the access policy is defined by a customer of the cloud provider to allow the customer to control access to the cloud infrastructure resource by an operator employee of the cloud provider. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention for the permission policies of Dani to have been defined by the client organization in order enable a given organization to specify the permissions granted in a given context as suggested by El Kalam (Page 6, left column, Section 4.8).
Referring to claim 18, Dani discloses that the permission policy includes criterion that identify the ability to automatically approve access control requests ([0029]-[0030]: criterion include user group criterion, flag criterion, action scope criterion, and schedule criterion; these criterion reads on the claimed keyword comprising text because these criterion from the permission policy would be textual and “indicative” of the ability to automatically approve requests, which would correspond to the claimed “override”), which meets the limitation of wherein the keyword comprises text included within the defined access policy and is indicative of an override condition that is checked to determine whether the access by the operator employee of the cloud provider is permitted without the requirement that the customer approve of the access request.
Referring to claim 19, Dani discloses that the request includes the identity of the requesting operator ([0019]) such that the corresponding user group of the requesting operator is checked against the permission policy user group criterion that dictates a user group whose access control requests can be automatically approved ([0029]-[0030]), which meets the limitation of wherein the access request comprises information evaluated for determining whether the customer approval override condition of the access policy is satisfied.
Referring to claim 20, Dani discloses that the access control request that identify an action that the operator wants to perform ([0019]), which meets the limitation of wherein the information of the access request includes at least one of a scope of access, a category of access, a reason for access.
Referring to claims 21, 22, Dani discloses that the permission policy includes criterion that identify the ability to automatically approve access control requests ([0029]-[0030]: criterion corresponding with request data can be considered a security incident that is checked against security ticketing), which meets the limitation of wherein the override condition of the access policy corresponds to a security incident, the security incident is checked against security ticketing.
Referring to claim 23, Dani discloses that the requested action can include performing a debugging trace ([0031]), which meets the limitation of wherein the cloud provider operator access that is performed without checking for the customer approval comprises a diagnosis operation.
Referring to claim 24, Dani discloses that the request includes the identity of the requesting operator ([0019]) such that the corresponding user group of the requesting operator is checked against the permission policy user group criterion that dictates a user group whose access control requests can be automatically approved ([0029]-[0030]). Automatic approval of the access control requests based on the criterion in the permission policy prevents authorization steps 316-330 from being performed (Figure 3). The user assignment to the particular user group can be temporary ([0025]), therefore, any further access control requests received from the operator after expiration of this temporary time period would require the additional authorization steps 316-330 (Figure 3), which meets the limitation of wherein multiple override requests are subject to an additional approval process.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BENJAMIN E LANIER whose telephone number is (571)272-3805. The examiner can normally be reached M-Th: 5:30-4:00.
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, Alexander Lagor can be reached at 5712705143. 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.
/BENJAMIN E LANIER/ Primary Examiner, Art Unit 2437
Prosecution Insights