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 non-final action is responsive to RCE filed on 08/27/2026. Claims 1-20 are pending, with claims 1, 19 and 20 being independent.
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 08/27/2026 has been entered.
Response to Arguments
Claim Objections
Objections have been withdrawn in view of amended claim.
35 U.S.C. § 103 Rejections
Applicants’ arguments have been fully considered but they are not persuasive.
On pages 4 and 5 of remarks, applicant argues that Kreiner's active/inactive status is a status of a multicast group membership, not a link status for a mapping between a governing tenancy and a subject tenancy.
Examiner respectfully disagrees. Claim 2 recites “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” (emphasis added). Thus, “link mapping data” is interpreted as data storing agreements/relationships between tenancies, and “link status” is interpreted as data showing status (e.g., active or inactive status) of the agreements/relationships between tenancies. Claim 1 is rejected by a combination of Vepa, McKenna, Kreiner. As shown in last rejection, Vepa in view of McKenna teaches a governing tenancy (e.g., entity A), a subject tenancy (e.g., entity B), a tenancy link (e.g., agreement/relationship between entity A and B), link mapping data (e.g., data showing agreement/relationship between entity A and B). Kreiner teaches status data (e.g., active/inactive status) for agreement/relationship between group addresses and device 120. For instance, if group A is active, the device will process messages transmitted to the device 120 via group A. If group A is inactive, the device will not process messages transmitted to the device 120 via group A. It would have been obvious to one skilled in the art to further modify the method of Vepa with the teaching of Kreiner to incorporate status data of Kreiner for the data showing agreement/relationship between entity A and B because it offers the advantage of improving data management and/or operational efficiency. Thus, combination of Vepa, McKenna, Kreiner teaches link status for a tenancy mapping.
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 the confirming 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.
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).
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. One of ordinary skilled in the art would have been motivated because it offers the advantage of authorizing operations performed 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 the group 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 10958431 B2; Authenticating Computing System Requests Across Tenants Of A Multi-tenant Database System
This patent document discloses techniques for using a central computing system to facilitate authenticating computing system requests across tenants of a multi-tenant database system.
US 11336453 B2; Transactions Between Services In A Multi-tenant Architecture
Embodiments of the present disclosure generally relate to the field of software architecture and, more particularly, to managing how various entities are on-boarded, managed, and/or accessed in a multi-tenant system architecture.
US 20210234864 A1; Method For Resource Access Across Organizations, Involves Receiving A Client Application Administrator Input From A Target Tenant Computing System, And Generating A Client Application Entry In A Target Tenant Scope
The method arranges authorization so the target service uses client credentials in obtaining authorization to access the resources and only perform operations defined by the permissions.
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