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 .
DETAILED ACTION
This final action is responsive to amendment filed on 04/01/2026. In this amendment, claims 1, 12, 19 and 20 have been amended. Claims 1-20 are pending, with claims 1, 19 and 20 being independent.
Response to Arguments
Claims Objections
Objections have been maintained because the issues have not been addressed.
35 U.S.C. § 112 Rejection
Rejection has been withdrawn in view of amended claims.
35 U.S.C. § 103 Rejections
Applicant’s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
On page 2 of the remarks, applicant argues that the present claims require a distinct mapping data repository. Examiner respectfully disagrees. The claims recite mapping data, not the mapping data repository. Mapping data and mapping data repository are not the same.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 02/16/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claims 10 and 14 are objected to because of the following informalities:
For claim 10, there is insufficient antecedent basis for “the partner”.
For claim 14, there is insufficient antecedent basis for “the initiation of an operation”.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 12-13, and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Vepa et al. (US 2017/0329957, published Nov. 16, 2017), McKenna et al. (US 2025/0392463, filed Jun. 24,2024) and Kreiner et al. (US 2012/0151561, published Jun. 14, 2012).
As per claim 1, Vepa discloses one or more non-transitory computer readable media comprising instructions which, when executed by one or more hardware processors, cause performance of operations comprising:
receiving a configuration request from a first service associated with a governing tenancy to configure a feature associated with a subject tenancy (Vepa par. 153, a user living in "tenant 1" may need to perform an action in an application owned by "tenant 2". Thus, the user needs to go to the resource namespace of "tenant 2" and request a token; Vepa par. 153, At 1301, a client (i.e., application) 1320 (e.g., application client 708 of FIG. 7) calls the OAuth service 1340 (e.g., resource server 720 of FIG. 7) with a POST/token request that corresponds to a resource where access is desired. The request may include user information and application information);
responsive to operation:
issuing a resource principal token that forms a basis for authorization for the first service within the governing tenancy to initiate actions, associated with the feature, within the subject tenancy (Vepa par. 248, At 1304, the response is the allowed scopes, which is computed and which is incorporated in the access token and sent back to client 1320 at 1305; Vepa par. 4, a system for authorizing access to a resource associated with a tenancy in an identity management system that includes a plurality of tenancies. The system receives an access token request for an access token that corresponds to the resource); and
responding to the configuration request with the resource principal token (Vepa par. 248, At 1304, the response is the allowed scopes, which is computed and which is incorporated in the access token and sent back to client 1320 at 1305).
Vepa does not explicitly disclose:
determining, at least by accessing link mapping data that stores mappings between tenancies including link status, if any active tenancy link has been established between the governing tenancy and the subject tenancy;
confirming based at least in part on the link mapping data indicating an active status for the mapping that an active tenancy link has been established between the governing tenancy and the subject tenancy, wherein the active tenancy link was established prior to the receipt of the configuration request;
responsive to the confirming operation:
issuing a resource principal token; and
responding to the configuration request with the resource principal token.
McKenna teaches:
determining, at least by accessing link mapping data that stores mappings between tenancies, if any active tenancy link has been established (McKenna par. 39, the DO 204 and the DNO 206 negotiate whether the DO 204 can perform the desired operation(s). If the DO 204 and the DNO 206 agree to the DO 204 performing the desired operation(s), the DNO 206 sends a contract token request 205 to the token generation service 208. The contract token request 205 indicates a condition of an agreement between the DNO 206 and the DO 204 that owns the data 201 stored in the DSS 202. The terms of the agreement can be codified by the token generation service 208 into the contract token 214, which is then sent back to the DNO 206. [Implicitly the service 208 identifies/determines/confirms the agreement/link between the DNO 206 and the DO 204]);
confirming based at least in part on the link mapping data for the mapping that an active tenancy link has been established (McKenna par. 39, the DO 204 and the DNO 206 negotiate whether the DO 204 can perform the desired operation(s). If the DO 204 and the DNO 206 agree to the DO 204 performing the desired operation(s), the DNO 206 sends a contract token request 205 to the token generation service 208. The contract token request 205 indicates a condition of an agreement between the DNO 206 and the DO 204 that owns the data 201 stored in the DSS 202. The terms of the agreement can be codified by the token generation service 208 into the contract token 214, which is then sent back to the DNO 206. [Implicitly the service 208 identifies/determines/confirms the agreement/link between the DNO 206 and the DO 204]), wherein the active tenancy link was established prior to the receipt of the configuration request (McKenna par. 39, the DO 204 and the DNO 206 negotiate whether the DO 204 can perform the desired operation(s). If the DO 204 and the DNO 206 agree to the DO 204 performing the desired operation(s), the DNO 206 sends a contract token request 205 to the token generation service 208);
responsive to the confirming operation: issuing a resource principal token; and responding to the configuration request with the resource principal token (McKenna par. 39, the DNO 206 sends a contract token request 205 to the token generation service 208. The contract token request 205 indicates a condition of an agreement between the DNO 206 and the DO 204 that owns the data 201 stored in the DSS 202. The terms of the agreement can be codified by the token generation service 208 into the contract token 214, which is then sent back to the DNO 206).
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to modify the method of Vepa with the teaching of McKenna to incorporate multi-party token-based authorization for determining, at least by accessing link mapping data that stores mappings between tenancies, if any active tenancy link has been established between the governing tenancy and the subject tenancy; confirming based at least in part on the link mapping data for the mapping that an active tenancy link has been established between the governing tenancy and the subject tenancy, wherein the active tenancy link was established prior to the receipt of the configuration request; responsive to the confirming operation: issuing a resource principal token; and responding to the configuration request with the resource principal token. One of ordinary skilled in the art would have been motivated because it offers the advantage of authorizing operations perform by other party.
Vepa-McKenna does not explicitly disclose:
link mapping data that including link status;
confirming based at least in part on data indicating an active status.
Kreiner teaches:
data that including status (Kreiner par. 44, an active/inactive status of thegroup membership);
confirming based at least in part on data indicating an active status (Kreiner par. 43, The first example multicast group membership 305 is active, meaning that the device will process messages).
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to further modify the method of Vepa with the teaching of Kreiner to incorporate status data for link mapping data that stores mappings between tenancies including link status and confirming based at least in part on the link mapping data indicating an active status for the mapping that an active tenancy link has been established. One of ordinary skilled in the art would have been motivated because it offers the advantage of improving data management and/or operational efficiency.
As per claim 2, Vepa-McKenna-Kreiner discloses the computer readable media of Claim 1, wherein active tenancy links are stored associations between a plurality of tenancies that represent active agreements authorizing initiation, from one of the tenancies, of operations in another tenancy under a set of defined conditions (Vepa par. 153, a user living in "tenant 1" may need to perform an action in an application owned by "tenant 2". Thus, the user needs to go to the resource namespace of "tenant 2" and request a token; McKenna par. 37, the DSS 202 enables the DO 204 to interact with the data 201 (e.g., perform a data operation 218) in accordance with the agreement between the DO 204 and the ONO 206 as defined by the contract token 214). The same rationale as in claim 1 applies.
As per claim 3, Vepa-McKenna-Kreiner discloses the computer readable media of Claim 2, wherein determining if any active tenancy link has been established between the governing tenancy and the subject tenancy comprises accessing link mapping data and determining if a mapping between the governing tenancy and the subject tenancy is stored in the link mapping data (Vepa par. 153, a user living in "tenant 1" may need to perform an action in an application owned by "tenant 2". Thus, the user needs to go to the resource namespace of "tenant 2" and request a token; McKenna par. 39, the DO 204 and the DNO 206 negotiate whether the DO 204 can perform the desired operation(s). If the DO 204 and the DNO 206 agree to the DO 204 performing the desired operation(s), the DNO 206 sends a contract token request 205 to the token generation service 208. The contract token request 205 indicates a condition of an agreement between the DNO 206 and the DO 204 that owns the data 201 stored in the DSS 202. The terms of the agreement can be codified by the token generation service 208 into the contract token 214, which is then sent back to the DNO 206. [Implicitly the service 208 identifies/determines/confirms the agreement/link between the DNO 206 and the DO 204]). The same rationale as in claim 1 applies.
As per claim 12, Vepa-McKenna-Kreiner discloses the computer readable media of Claim 1, further comprising:
receiving a configuration request from the first service associated with a governing tenancy to configure a second feature associated with a target tenancy that is different from the subject tenancy (Vepa par. 152-153, When a request is submitted, there can be multiple tenancies involved in the request… As another example, a user living in "tenant 1" may need to perform an action in an application owned by "tenant 2". Thus, the user needs to go to the resource namespace of "tenant 2" and request a token; Vepa par. 153, At 1301, a client (i.e., application) 1320 (e.g., application client 708 of FIG. 7) calls the OAuth service 1340 (e.g., resource server 720 of FIG. 7) with a POST/token request that corresponds to a resource where access is desired. The request may include user information and application information. [One tenant (e.g., tenant 1) may need to perform an action in an application owned by other tenant (e.g., tenant 4), would have been obvious, if not inherent, in order to provide authorizing access to a resource in environment including a plurality of tenancies]); and
responsive to determining that an active tenancy link has been established between the governing tenancy and the target tenancy (McKenna par. 39, the DO 204 and the DNO 206 negotiate whether the DO 204 can perform the desired operation(s). If the DO 204 and the DNO 206 agree to the DO 204 performing the desired operation(s), the DNO 206 sends a contract token request 205 to the token generation service 208. The contract token request 205 indicates a condition of an agreement between the DNO 206 and the DO 204 that owns the data 201 stored in the DSS 202. The terms of the agreement can be codified by the token generation service 208 into the contract token 214, which is then sent back to the DNO 206. [Implicitly the service 208 identifies/determines/confirms the agreement/link between the DNO 206 and the DO 204]; Vepa par. 152-153, When a request is submitted, there can be multiple tenancies involved in the request… As another example, a user living in "tenant 1" may need to perform an action in an application owned by "tenant 2"):
issuing a target resource principal token that authorizes the first service within the governing tenancy to initiate actions, associated with the second feature, within the target tenancy (McKenna par. 39, the DNO 206 sends a contract token request 205 to the token generation service 208. The contract token request 205 indicates a condition of an agreement between the DNO 206 and the DO 204 that owns the data 201 stored in the DSS 202. The terms of the agreement can be codified by the token generation service 208 into the contract token 214, which is then sent back to the DNO 206; Vepa par. 152-153, When a request is submitted, there can be multiple tenancies involved in the request… As another example, a user living in "tenant 1" may need to perform an action in an application owned by "tenant 2"). The same rationale as in claim 1 applies.
As per claim 13, Vepa-McKenna-Kreiner discloses the computer readable media of Claim 1, further comprising:
receiving a configuration request from a managing service associated with a supervising tenancy to configure a second feature associated with the governing tenancy (Vepa par. 152-153, When a request is submitted, there can be multiple tenancies involved in the request… As another example, a user living in "tenant 1" may need to perform an action in an application owned by "tenant 2". Thus, the user needs to go to the resource namespace of "tenant 2" and request a token; Vepa par. 153, At 1301, a client (i.e., application) 1320 (e.g., application client 708 of FIG. 7) calls the OAuth service 1340 (e.g., resource server 720 of FIG. 7) with a POST/token request that corresponds to a resource where access is desired. The request may include user information and application information. [One tenant (e.g., tenant 5) may need to perform an action in an application owned by other tenant (e.g., tenant 1), would have been obvious, if not inherent, in order to provide authorizing access to a resource in environment including a plurality of tenancies]); and
in response to determining if any active tenancy link has been established between the supervising tenancy and the governing tenancy (McKenna par. 39, the DO 204 and the DNO 206 negotiate whether the DO 204 can perform the desired operation(s). If the DO 204 and the DNO 206 agree to the DO 204 performing the desired operation(s), the DNO 206 sends a contract token request 205 to the token generation service 208. The contract token request 205 indicates a condition of an agreement between the DNO 206 and the DO 204 that owns the data 201 stored in the DSS 202. The terms of the agreement can be codified by the token generation service 208 into the contract token 214, which is then sent back to the DNO 206. [Implicitly the service 208 identifies/determines/confirms the agreement/link between the DNO 206 and the DO 204]; Vepa par. 152-153, When a request is submitted, there can be multiple tenancies involved in the request… As another example, a user living in "tenant 1" may need to perform an action in an application owned by "tenant 2"):
issuing a resource principal token that authorizes the managing service within the supervising tenancy to initiate actions, associated with the second feature, within the governing tenancy (McKenna par. 39, the DNO 206 sends a contract token request 205 to the token generation service 208. The contract token request 205 indicates a condition of an agreement between the DNO 206 and the DO 204 that owns the data 201 stored in the DSS 202. The terms of the agreement can be codified by the token generation service 208 into the contract token 214, which is then sent back to the DNO 206; Vepa par. 152-153, When a request is submitted, there can be multiple tenancies involved in the request… As another example, a user living in "tenant 1" may need to perform an action in an application owned by "tenant 2"). The same rationale as in claim 1 applies.
As per claim 15, Vepa-McKenna-Kreiner discloses the computer readable media of Claim 1, further comprising:
sending, from the first service to a service associated with the subject tenancy, a feature initiation request to initiate an action associated with the feature (Vepa par. 153, a user living in "tenant 1" may need to perform an action in an application owned by "tenant 2". Thus, the user needs to go to the resource namespace of "tenant 2" and request a token; Vepa par. 255, At 1401, a REST request (or “access authorization request”) is made by client 1320 through a microservice); and
wherein the feature initiation request includes the principal token (Vepa par. 255-256, a security filter 1420 intercepts the request at 1403… At 1404, the access token is extracted).
As per claim 16, Vepa-McKenna-Kreiner discloses the computer readable media of Claim 1, further comprising:
receiving a feature initiation request from the first service to initiate an action associated with the feature (Vepa par. 153, a user living in "tenant 1" may need to perform an action in an application owned by "tenant 2". Thus, the user needs to go to the resource namespace of "tenant 2" and request a token; Vepa par. 255, At 1401, a REST request (or “access authorization request”) is made by client 1320 through a microservice); and
wherein the feature initiation request includes the principal token (Vepa par. 255-256, a security filter 1420 intercepts the request at 1403… At 1404, the access token is extracted).
As per claim 17, Vepa-McKenna-Kreiner discloses the computer readable media of Claim 16, further comprising:
in response to determining that the principal token is valid, initiating the action within the subject tenancy (Vepa par. 261, At 1407, the allowed scopes from PEP API 1360 is used in conjunction with S, RT, A to determine if access is denied or allowed and then this determination is returned at 1408 to the IDCS REST resource server; see Vepa Fig. 14 after step 1408, if allow, proceed to invoke service).
As per claim 18, Vepa-McKenna-Kreiner discloses the computer readable media of Claim 1, wherein the configuration request identifies:
the governing tenancy (Vepa par. 261, At 1401, a REST request (or “access authorization request”) is made by client 1320 through a microservice. For example, the request may be to create a new user. The payload will have information about the user);
the feature (Vepa par. 261, At 1401, a REST request (or “access authorization request”) is made by client 1320 through a microservice. For example, the request may be to create a new user; Vepa Fig. 14 after step 1408, if allow, proceed to invoke service); and
a subject tenancy (Vepa par. 261, At 1401, a REST request (or “access authorization request”) is made by client 1320 through a microservice. For example, the request may be to create a new user; Vepa Fig. 14 after step 1408, if allow, proceed to invoke service).
Claim 19 does not teach or further define over the limitations in claim 1. As such, claim 19 is rejected for the same reasons as set forth in claim 1.
Claim 20 does not teach or further define over the limitations in claim 1. As such, claim 20 is rejected for the same reasons as set forth in claim 1.
Claims 11 is rejected under 35 U.S.C. 103 as being unpatentable over Vepa et al. (US 2017/0329957, published Nov. 16, 2017), McKenna et al. (US 2025/0392463, filed Jun. 24,2024), Kreiner et al. (US 2012/0151561, published Jun. 14, 2012) and Engelhart (US 2014/0282990, published Sep. 18, 2014).
As per claim 11, Vepa-McKenna-Kreiner discloses the computer readable media of Claim 1, further comprising:
receiving a request from the first service to perform an operation associated with the subject tenancy (Vepa par. 153, a user living in "tenant 1" may need to perform an action in an application owned by "tenant 2". Thus, the user needs to go to the resource namespace of "tenant 2" and request a token; Vepa par. 255, At 1401, a REST request (or “access authorization request”) is made by client 1320 through a microservice), wherein the request is associated with the resource principal token (Vepa par. 255-256, a security filter 1420 intercepts the request at 1403… At 1404, the access token is extracted);
determining that the resource principal token is no longer valid (Vepa par. 264, An EP enforcement point 1501 is part of an Oracle Traffic Director (“OTD”) 1502 to determine whether the access token has expired or is valid); and
responsive to confirming that an active tenancy link exists between the governing tenancy and the subject tenancy (McKenna par. 39, the DO 204 and the DNO 206 negotiate whether the DO 204 can perform the desired operation(s). If the DO 204 and the DNO 206 agree to the DO 204 performing the desired operation(s), the DNO 206 sends a contract token request 205 to the token generation service 208. The contract token request 205 indicates a condition of an agreement between the DNO 206 and the DO 204 that owns the data 201 stored in the DSS 202. The terms of the agreement can be codified by the token generation service 208 into the contract token 214, which is then sent back to the DNO 206), issuing a resource principal token that authorizes the first service within the governing tenancy to initiate actions, associated with the feature, within the subject tenancy (McKenna par. 39, the DNO 206 sends a contract token request 205 to the token generation service 208. The contract token request 205 indicates a condition of an agreement between the DNO 206 and the DO 204 that owns the data 201 stored in the DSS 202. The terms of the agreement can be codified by the token generation service 208 into the contract token 214, which is then sent back to the DNO 206; Vepa par. 152-153, When a request is submitted, there can be multiple tenancies involved in the request… As another example, a user living in "tenant 1" may need to perform an action in an application owned by "tenant 2"). The same rationale as in claim 1 applies.
Vepa-McKenna-Kreiner discloses issuing a resource principal token, but does not explicitly disclose issuing a replacement resource principal token.
Engelhart teaches:
issuing a replacement resource principal token (Engelhart par. 23, When a token is expiring, the token management component 208 may take appropriate measures, such as generating a new replacement token, sending the replacement token to the mobile device 106).
It would have been obvious to one skilled in the art before the effective filing date of the claimed invention to further modify the method of Vepa with the teaching of Engelhart for responsive to confirming that an active tenancy link exists between the governing tenancy and the subject tenancy, issuing a replacement resource principal token that authorizes the first service within the governing tenancy to initiate actions, associated with the feature, within the subject tenancy. One of ordinary skilled in the art would have been motivated because it offers the advantage of managing the token for providing access control.
Allowable Subject Matter
Claims 4-10 and 14 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten to overcome the objections and to include all of the limitations of the base claim and any intervening claims because none of the prior art of record either taken by itself or in any combination teaches all limitations as currently presented in the claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 12079220 B2; Data Analytics Platform Using Configurable Flow Specifications
The present disclosure relates to a serverless multi-tenancy data analytics platform configured to process parameterized flow specifications and provide analysis results using a variety of interfaces.
US 11695559 B2; Nested Tenancy That Permits A Hierarchy Having A Plurality Of Levels
A multi-tenant computer system implements a platform for providing data protection scopes to shared infrastructure services according to a nested tenant model that permits a hierarchy having a plurality of levels.
US 11381571 B2; Authentication Framework For Resource Access Across Organizations
A client application is specified by a target tenant and represented in an OAuth provider, along with a corresponding secret. A source tenant consents to permissions to be executed by the client application on a resource of the source tenant. A target service uses the secret to obtain an access token from an authorization server coupled to the source tenant and uses the access token to obtain access, specified by the permissions, to the resource served by a source service acting on behalf of the source tenant.
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 KHANG DO whose telephone number is (571)270-7837. The examiner can normally be reached Monday-Friday 8:00 - 5:00 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, RUPAL DHARIA can be reached at (571) 272-3880. 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.
/KHANG DO/Primary Examiner, Art Unit 2492
Prosecution Insights