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 .
Claims 1-24 are pending.
Information Disclosure Statement
The IDSs filed 3/29/2024, 5/29/2024, 6/17/2024, 7/16/2024, 8/20/2024, 6/20/2025, 7/30/2025, 8/19/2025, 8/27/2025, and 10/30/2025 have been considered by the Examiner.
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 12-16 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 to claims 12-16, the “pre-approval” process is the same as the claimed approval request. The whole “pre-approval” process is the claimed approval process just done by some other entity other than the IAM service. The approval service is used to store the result of the “pre-approval” process. It is not clear why the approval service would need to repeat all the steps of the pre-approval process in order to grant access to the resource if the pre-approval process has already carried out the approval steps. The limitations just add unnecessary and superfluous steps and layers to the process.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3 and 8-20 are rejected under 35 U.S.C. 102(a) as being anticipated by US PG Pub. No. 2024/0179146 to Pinski et al. (hereinafter Pinski).
As to claims 1, 21, and 23, Pinski teaches one or more non-transitory computer-readable media storing instructions, which when executed by one or more hardware processors (Pinski, [0130 and 0142]), cause performance of operations comprising :
a. Receiving, from a computing entity associated with a recipient principle to access a target resource based on one or more access policies associated with a delegate principal (assuming service acting in the delegation role sends request to temporary credential service to assume customer role and access the customer resource) (Pinski, [0020]).
b. The delegate principal comprises an identity representation that is delegable to the recipient principal to enable the computing entity associated with the recipient principle to access the target resource based on the one or more access policies associated with the delegate principle (delegated entity can access the resource while adhering to the least privilege principle that only allows specific access rights) (Pinski, [0022]).
c. The credential request comprises: a recipient principal-identifier, wherein the recipient principal-identifier identifies the recipient principal and a target resource-identifier, wherein the target resource-identifier identifies the target resource (IAM service uses request context to define what is allowed including the resource being requested and the request principal among other metadata) (Pinski, [0094]).
d. Transmitting to an approval service associated with the target resource, an approval request for the approval service to approve issuance of the delegate credential to the recipient principal (IAM service approves requests) (Pinski, [0094]).
e. The approval request comprises the recipient principal-identifier and the target resource-identifier (approval of the request) (Pinski, [0094-00995]).
f. Receiving an approval confirmation from the approval service (successful assumption of the role) (Pinski, [0094-0095]).
g. The approval service approves the approval request based at least on the recipient principal-identifier and the target resource-identifier (approval of the request) (Pinski, [0094-0095]).
h. The approval confirmation comprises a delegate principal-identifier, the one or more access policies associated with the delegate principal are identifiable in an identity access management system based at least in part on the delegate principal-identifier (IAM restricts the permission policy to only the permissions necessary to execute the operation(s)) (Pinski, [0080-0081]).
i. Responsive to receiving the approval confirmation, generating the delegate credential, wherein the delegate credential comprises the delegate principal-identifier (temporary credential issued) (Pinski, [0080-0081]).
j. Transmitting the delegate credential to the computing entity associated with the recipient principal (temporary credential issued) (Pinski, [0080-0081]).
k. The computing entity associated with the recipient principal accesses the target resource based on the identity representation of the delegate principal at least by presenting to a resource service associated with the target resource, the delegate credential and an access request to access the target resource (temporary credential issued) (Pinski, [0080-0081]).
l. The resource service authorizes the computing entity to access the target resource based on the one or more access policies associated with the delegate principal, the resource service identifies the one or more access policies in the identity access management system based on the delegate principal-identifier (temporary credential issued) (Pinski, [0080-0081]).
As to claim 2, Pinski teaches the resource service authorizes the computing entity to access the target resource based on successfully validating that the recipient principal-identifier of the delegate credential corresponds to the recipient principal utilizing the computing entity (temporary credential issued) (Pinski, [0080-0081]).
As to claim 3, Pinski teaches the recipient principal comprises a user principal, wherein the user principal represents an identity of a particular user (the delegation role assumes the customer role (representing a particular user) (Pinski, [0080-0081]).
As to claims 8 and 24, Pinsky teaches:
a. The one or more access policies associated with the delegate principal include a permission to access a first compartment (requested resource can be partitioned) (Pinsky, [0047]).
b. The first compartment comprise a first set of one or more logical containers (requested resource are organized into containers) (Pinsky, [0130-0131]).
c. The target resource is located within the first set of one or more logical containers (requested resource are organized into containers) (Pinsky, [0130-0131]).
d. A second access policy comprising a second permission to access a second compartment (requested resource can be partitioned) (Pinsky, [0047]).
e. The second compartment comprises a second set of one or more logical containers associated with a tenant of a cloud infrastructure (requested resource are organized into containers) (Pinsky, [0130-0131]).
f. The second set of one or more logical containers comprises the first set of one or more logical containers (requested resource are organized into containers) (Pinsky, [0130-0131]).
g. The target resource is provisioned by the tenant (customer (tenant) organizes their resources) (Pinsky, [0028]).
h. A third access policy comprising a third permission to access a third compartment (requested resource can be partitioned) (Pinsky, [0047]).
i. The third compartment comprises a third set of one or more logical containers associated with a cloud provider (requested resource are organized into containers) (Pinsky, [0130-0131]).
j. The third set of one or more logical containers comprises the second set of one or more logical containers (requested resource are organized into containers) (Pinsky, [0130-0131]).
k. The cloud infrastructure is provisioned by the cloud provider (provider network can be any of several cloud models) (Pinsky, [0033]).
It is noted that Pinsky does not restrict the delegation scheme and is not limited to a single access policy per delegation. The organization of the resource(s) is not in and of itself considered a patentable distinction. It is viewed as a data structure.
As to claim 9, Pinsky teaches:
a. Determining the approval service based on the target resource or the target resource-identifier (IAM service controls access to the resources in the provider network) (Pinsky, [0094-0095]).
b. The approval service is one of a set of approval services respectively corresponding to at least one of a set of resources (there can be multiple provider networks that can be controlled by different IAMs) (Pinsky, [0094]).
c. The set of resources comprises the target resource (IAM service controls access to the resources in the provider network) (Pinsky, [0094-0095]).
d. Transmitting the approval request to the approval service subsequent to determining the approval service (IAM service controls access to the resources in the provider network) (Pinsky, [0094-0095]).
As to claim 10, Pinsky teaches:
a. The approval service receives the approval request (IAM service evaluates and authorizes the request based on a request context based on the action to be performed, request principle, environment data, user agent, and other contexts including resource data) (Pinsky, [0094-0095]).
b. The approval service determines that the approval request meets one or more approval criteria, comprising at least one of: the recipient principal is pre-approved to obtain the delegate credential, the recipient principal-identifier matches a first data item in an approval data corpus, or the target resource-identifier matches a second data item in the approval data corpus (IAM service evaluates and authorizes the request based on a request context based on the action to be performed, request principle, environment data, user agent, and other contexts including resource data) (Pinsky, [0094-0095]).
c. The approval service grants the approval request responsive to determining that the approval request meets the one or more approval criteria (IAM restricts the permission policy to only the permissions necessary to execute the operation(s)) (Pinski, [0080-0081]).
As to claim 11, Pinsky teaches the approval service configures the identity access management system to include the one or more access policies associated with the delegate principal or determines that the identity access management system includes one or more access policies associated with the delegate principal wherein the approval service generates the approval confirmation (IAM service evaluates and authorizes the request based on a request context based on the action to be performed, request principle, environment data, user agent, policy requirements, and other contexts including resource data) (Pinsky, [0094-0095]).
As to claims 12-16 are redundant steps of the rejected limitations of independent claim 1 and are therefore rejected in similar fashion. Pinsky teaches that the delegation system needs no human interaction (Pinsky, [0027]) which is an advancement over depending on humans to determine approval authority.
As to claim 17, Pinsky teaches:
a. The approval service generates an access policy request comprising a request for the identity access management system to generate the one or more access policies associated with the delegate credential (permission policy is generated by the customer of the IAM and distributed throughout the system) (Pinsky, [0055-0056]).
b. The approval service transmits the access policy request to the identity access management system (permission policy is generated by the customer of the IAM and distributed throughout the system) (Pinsky, [0055-0056]).
c. The identity access management system generates the one or more access policies (permission policy is generated by the customer of the IAM and distributed throughout the system to be applied by the particular delegate that has sent in an access request) (Pinsky, [0055-0056]).
d. The identity access management system associates the delegate principal-identifier with the one or more access policies (permission policy is generated by the customer of the IAM and distributed throughout the system) (Pinsky, [0055-0056 and 0067]).
e. The identity access management system transmits the access policy confirmation to the approval service (permission policy is generated by the customer of the IAM and distributed throughout the system) (Pinsky, [0055-0056 and 0067]).
f. The approval service receives the access policy confirmation (permission policy is used in the IAM) (Pinsky, [0077-0078]).
g. The approval service generates the approval confirmation subsequent to receiving the access policy confirmation (permission policy is used in the IAM) (Pinsky, [0077-0078]).
As to claim 18, Pinsky teaches the recipient principal cannot directly access the target resource without using the delegate principal (the requester cannot access the resource(s) without the issued temporary credential) (Pinski, [0080-0081]).
As to claim 19, Pinsky teaches:
a. The computing entity associated with the recipient principal accesses a second target resource based on a second identity representation of the recipient principal at least by presenting to a second resource service associated with the second target resource, a recipient principal credential and a second access request to access the second target resource (approval of the request) (Pinski, [0094-0095]).
b. The second resource service authorizes the computing entity to access the second target resource based on a second set of one or more access policies associated with the recipient principal (temporary credential issued) (Pinski, [0080-0081]). The permission policy is not limited to a single resource per delegation (Pinski, [0080-0078]).
As to claim 20, Pinski teaches the delegate principle is usable only in connection with the recipient principal (the requester cannot access the resource(s) without the issued temporary credential) (Pinski, [0080-0081]).
Claims 4-7 and claim 22 are rejected under 35 U.S.C. 103 as being unpatentable over US PG Pub. No. 2024/0179146 to Pinski et al. (hereinafter Pinski) as applied to claim 1 and claim 21 respectively above, and further in view of US PG Pub. No. 2021/0075870 to Kempf et al. (hereinafter Kempf).
As to claims 4 and 22, Pinski teaches:
a. The access request comprises a digital signature (accessed request signed by a secret key) (Pinski, [0095 and 0099]).
Pinski does not expressly mention signing the request with a private key. However, in an analogous art, Kempf teaches signing the request with a generated private key associated with the recipient principal (selected service request is signed with the private key of the requestor) (Kempf, [0028 and 0047]).
Therefore, one or ordinary skill in the art before the effective filing date of the instant application would have been motivated to implement the delegation scheme of Pinsky with the use for private key of the requestor to sign a request of Kempf in order to make the delegation more secure as suggested by Kempf (Kempf, [0007]).
Pinsky as modified further teaches:
b. The resource service performs a validation of the digital signature against a public key corresponding to the private key, wherein the validation indicates that the digital signature corresponds to the public key (each entity has its own public/private key pair that is used to identify the entity requesting delegation) (Kempf, [0050]).
c. The resource service authorizes the computing entity to access the target resource based on the validation indicating that the digital signature corresponds to the public key (the identified requestor/recipient is granted the access and the identity is used to determine at least the scope of access as well as any fee for the delegation) (Kempf, [0050-0052]).
As to claim 5, Pinsky as modified teaches the public key is included in the delegate credential or the public key is included in a recipient credential associated with the recipient principal, where the recipient credential is presented to the resource service along with the delegate credential and the access request (the public key of the requestor is registered and known to the parties involved in the delegation scheme) (Kempf, [0050-0052]).
As to claim 6, Pinsky as modified teaches the credential request comprises the public key, and the public key and the private key are generated by the computing entity or generating the public key and the private key and transmitting the private key to the computing entity (public/private keys are generated for the service) (Kempf, [0055]). Kempf does not explicitly recite where the public/private keys are generated. However, the limitations cover the two options for key generation (e.g., either the keys are generated by the requestor or the keys are generated by the service and sent to the requestor).
As to claim 7, Pinsky as modified teaches:
a. The resource service determines that the one or more access policies associated with the delegate principal include a permission to access the target resource (the recipient is granted access to the resource based on the identity of the recipient) (Kempf, [0052]).
b. The resource service authorizes the computing entity to access the target resource based additionally on having determined that the one or more access policies associated with the delegate principal include the permission to access the target resource (the recipient is granted access to the resource based on the identity of the recipient) (Kempf, [0052]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to WILLIAM S POWERS whose telephone number is (571)272-8573. The examiner can normally be reached M-F 7:30-17:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jorge L Ortiz-Criado can be reached at (571) 272-7624. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/WILLIAM S POWERS/Primary Examiner, Art Unit 2496
Prosecution Insights