DETAILED ACTION
This action is in response to the amendment filed on June 16, 2026. Claims 1, 11, and 12 have been amended, claims 7-9 and 17-19 have been canceled and claims 23-26 are new. Claims 1-6, 10-16, 20-26 are pending. Of such, claims 1-6 and 10 represent a method and claims 11-16 and 20-26 represent a system directed to asset access control.
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 .
Response to Arguments
Applicant’s arguments with respect to the amendments, see Remarks, filed June 16, 2026, with respect to the rejection(s) of claim(s) 1-5, 10-15, and 20-22 under 35 U.S.C. 102(a)(1) in view of Tran have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Tran and Gupta.
Applicant's arguments with respect to Tran in view of Gupta filed June 16, 2026 have been fully considered but they are not persuasive.
On pages 8-9 of the Remarks, the Applicant argues that Tran and Gupta do not teach updating a local application feature library based on the remote application feature library. Applicant argues that Gupta’s Identity Cloud Service (IDCS) is an identify cloud service platform rather than a remote application feature library. The remote application feature library, however, is Tran’s, not Gupta’s. As disclosed in the Non-Final action submitted on March 20, 2026, “the examiner interprets the third application as the management node and the service registry as the application feature library”. Gupta is cited for one function, keeping a local store in sync with the remote one. Gupta teaches this in ¶¶47-47, where the Cloud Cache is synchronized with a remote store over the System for Cross-domain Identity Management (SCIM) identity bus and pulls data from it. Applied to Tran, the local application feature library is updated from the service registry. The note the Applicant quotes accompanied the rejection of claim 8, which has now been cancelled. It identified which side of Gupta’s own local/remote pair was being borrowed. It was not the mapping of the application feature library. Due to the amendment to claim 1 and the introduction of the limitations from claim 8 into claim 1, the mapping is restated above against the amended claim language. Further, non-obviousness is not shown by attacking the references individually where the rejection is based on their combination. See MPEP 2145(IV); In re Keller, 642 F.2d 413, 426 (CCPA 1981).
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.
Claims 1-5, 10-15, and 20-26 are rejected under 35 U.S.C. 103 as being unpatentable over Tran, William (US 20180219863), hereinafter referred to as Tran, in view of Gupta et al. (US 20180041515), hereinafter referred to as Gupta.
Regarding Claim 1, Tran discloses:
An asset access control method (In ¶ 5, Tran discloses “the disclosed techniques improve upon conventional authorization technology in a microservice-based computing platform by authenticating and authorizing chains of invocations that cross multiple trust boundaries to service a user's request.”), comprising: obtaining a first identity feature of an application chain (In ¶ 22, Tran discloses “The authentication token 126 includes the initial token 124, an instance identifier of the running instance of the first application 108, as well as the invocation request method and path to be executed.” wherein the examiner interprets the first identity feature as the authentication token of the invocation path (i.e. application chain)), wherein the first identity feature comes from a logic of an application in the application chain (In ¶ 22, Tran discloses “The first application 108 then sends the authentication token 126 and the signed body, if any, to the second application 110 in association with an invocation request.”); sending, to a management node, the first identity feature to compare the first identity feature with a second identity feature that is of the application chain and that is recorded in a remote application feature library (In ¶ 25-26, Tran discloses “the third application 112 can authenticate the received authentication token 128…The third application 112 authenticates the invocation request by verifying the authentication token 128 using a public key in the service registry 106 to determine whether the invocation request is a legitimate invocation request.” wherein the examiner interprets the third application as the management node and the service registry as the application feature library) allowing the application chain to access an asset when the first identity feature matches the second identity feature (In ¶ 58, Tran discloses “The third application verifies that the intent of the second application 110 as specified in the signed authentication token 128 corresponds with the operation to be performed, and performs the operation upon successful verification.”);
However, Tran does not explicitly disclose the concept of two different feature libraries.
Gupta discloses:
and updating a local application feature library based on the remote application feature library (In ¶ 47, Gupta discloses “SCIM identity bus 234 is used to synchronize data in IDCS 202 with on-premise LDAP data called “Cloud Cache” 402” and further in ¶ 48 “Cloud Cache 402 establishes a connection to IDCS 202 and then pulls data from IDCS 202 as it is being requested… Cloud Cache 402 may use SCIM bus 234 to send a SCIM request to IDCS 202 and receive corresponding data in return.”)
One in ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Tran’s approach by utilizing Gupta’s approach of utilizing a local and remote library as the motivation would be to reduce the latency of connecting to a remote server (See Gupta, ¶ 96)
Regarding Claim 2, the combination of Tran and Gupta disclose:
The asset access control method of claim 1, wherein the logic comprises: an input/output device of the application or execution of an input/output operation by the input/output device; or an interface invoking device of the application or execution of an interface invoking operation by the interface invoking device (In ¶ 29, Tran discloses “The first application 108 submits the authentication token 126 to the second application 110 in association with the invocation request, for example, as an HTTP header of the invocation request.”)
Regarding Claim 3, the combination of Tran and Gupta disclose:
The asset access control method of claim 1, wherein obtaining the first identity feature comprises performing feature extraction on the application chain to obtain the first identity feature (In ¶ 22, Tran discloses “the first application 108 creates its own authentication token 126. The authentication token 126 includes the initial token 124, an instance identifier of the running instance of the first application 108, as well as the invocation request method and path to be executed.”).
Regarding Claim 4, the combination of Tran and Gupta disclose:
The asset access control method of claim 3, wherein performing the feature extraction comprises performing the feature extraction on the application chain each time before the application chain accesses the asset (In ¶ 27, Tran discloses “The authentication tokens 126 and 128 can be single use tokens, ensuring that each of the authentication tokens 126 and 128 can be used to authenticate an invocation request only once, and only for an intended use.”).
Regarding Claim 5, the combination of Tran and Gupta disclose:
The asset access control method of claim 1, wherein obtaining the first identity feature comprises obtaining the first identity feature when an attribute of the asset is a target attribute (In ¶ 40, Tran discloses “the first application 108 can request specific scopes, which are values that indicate what can be done with the initial token 124.”).
Regarding Claim 10, the combination of Tran and Gupta disclose:
The asset access control method of claim 1, wherein the asset comprises a local credential, a remote credential, or an application programming interface for accessing a target service (In ¶ 52, Tran discloses “For HTTP requests, this claim can include the request method, path and query component of the request URI, e.g., “GET /api/accounts?type=trading.””).
Regarding Claim 11, Tran discloses:
An access control system (In ¶ 5, Tran discloses “the disclosed techniques improve upon conventional authorization technology in a microservice-based computing platform by authenticating and authorizing chains of invocations that cross multiple trust boundaries to service a user's request.”), comprising: an access control node configured to: obtain a first identity feature of an application chain (In ¶ 22, Tran discloses “The authentication token 126 includes the initial token 124, an instance identifier of the running instance of the first application 108, as well as the invocation request method and path to be executed.” wherein the examiner interprets the first identity feature as the authentication token of the invocation path (i.e. application chain)), wherein the first identity feature comes from a logic of an application in the application chain and send the first identity feature (In ¶ 22, Tran discloses “The first application 108 then sends the authentication token 126 and the signed body, if any, to the second application 110 in association with an invocation request.”); and a management node configured to: receive the first identity feature (In ¶ 25, Tran discloses “the third application 112 can authenticate the received authentication token 128”); and compare the first identity feature with a second identity feature that is of the application chain and that is recorded in a remote application feature library (In ¶ 26, Tran discloses “The third application 112 authenticates the invocation request by verifying the authentication token 128 using a public key in the service registry 106 to determine whether the invocation request is a legitimate invocation request.” wherein the examiner interprets the third application as the management node and the service registry as the application feature library), wherein the access control node is further configured to allow the application chain to access an asset when the first identity feature matches the second identity feature (In ¶ 58, Tran discloses “The third application verifies that the intent of the second application 110 as specified in the signed authentication token 128 corresponds with the operation to be performed, and performs the operation upon successful verification.”).
However, Tran does not explicitly disclose the concept of two different feature libraries.
Gupta discloses:
and updating a local application feature library based on the remote application feature library (In ¶ 47, Gupta discloses “SCIM identity bus 234 is used to synchronize data in IDCS 202 with on-premise LDAP data called “Cloud Cache” 402” and further in ¶ 48 “Cloud Cache 402 establishes a connection to IDCS 202 and then pulls data from IDCS 202 as it is being requested… Cloud Cache 402 may use SCIM bus 234 to send a SCIM request to IDCS 202 and receive corresponding data in return.”)
One in ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Tran’s approach by utilizing Gupta’s approach of utilizing a local and remote library as the motivation would be to reduce the latency of connecting to a remote server (See Gupta, ¶ 96)
Regarding Claim 12, the combination of Tran and Gupta disclose the limitations of Claim 11.
However, Tran does not explicitly disclose the concept of a scheduling device.
Gupta discloses:
The access control system of claim 11, wherein the logic comprises: a resource scheduling device of the application or execution of scheduling a resource by the resource scheduling device (In ¶ 89, Gupta discloses “The IDCS infrastructure services support the functionality of IDCS platform services. These runtime services include a job scheduler service (for scheduling and executing jobs, e.g., executing immediately or at a configured time long-running tasks that do not require user intervention)”).
One in ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Tran’s approach by utilizing Gupta’s approach of utilizing a scheduling device as the motivation would be to offload tasks not subject to real-time processing to an asynchronous scheduling mechanism enables the system to provide a high level of service by reducing latencies in response times (See Gupta, ¶ 96)
Regarding Claim 13, the combination of Tran and Gupta disclose:
The access control system of claim 11, wherein the access control node is further configured to perform feature extraction on the application chain to obtain the first identity feature (In ¶ 22, Tran discloses “the first application 108 creates its own authentication token 126. The authentication token 126 includes the initial token 124, an instance identifier of the running instance of the first application 108, as well as the invocation request method and path to be executed.”).
Regarding Claim 14, the combination of Tran and Gupta disclose:
The access control system of claim 13, wherein the access control node is further configured to perform the feature extraction on the application chain each time before the application chain accesses the asset (In ¶ 27, Tran discloses “The authentication tokens 126 and 128 can be single use tokens, ensuring that each of the authentication tokens 126 and 128 can be used to authenticate an invocation request only once, and only for an intended use.”).
Regarding Claim 15, the combination of Tran and Gupta disclose:
The access control system of claim 11, wherein the access control node is further configured to obtain the first identity feature when an attribute of the asset is a target attribute (In ¶ 40, Tran discloses “the first application 108 can request specific scopes, which are values that indicate what can be done with the initial token 124.”).
Regarding Claim 20, the combination of Tran and Gupta disclose:
The access control system of claim 11, wherein the asset comprises a local credential (In ¶ 40, Tran discloses “The initial token 124 can have a scope claim specifying a scope of the initial token 124.”).
Regarding Claim 21, the combination of Tran and Gupta disclose:
The access control system of claim 11, wherein the asset comprises a remote credential (In ¶ 37, Tran discloses “The service registry 106 has a metadata data field for storing the metadata provided by the applications. The metadata can include, in addition to the public key, a destination field, which specifies an invocation action that is permissible.”)
Regarding Claim 22, the combination of Tran and Gupta disclose:
The access control system of claim 11, wherein the asset comprises an application programming interface for accessing a target service (In ¶ 52, Tran discloses “For HTTP requests, this claim can include the request method, path and query component of the request URI, e.g., “GET /api/accounts?type=trading.””).
Regarding Claim 23, the combination of Tran and Gupta disclose:
The access control system of claim 11, wherein the logic comprises a command execution device of the application or execution of a command by the command execution device. (In ¶ 58, Tran discloses “The third application verifies that the intent of the second application 110 as specified in the signed authentication token 128 corresponds with the operation to be performed, and performs the operation upon successful verification.”)
Regarding Claim 24, the combination of Tran and Gupta disclose:
The access control system of claim 11, wherein the logic comprises an input/output device of the application or execution of an input/output operation by the input/output device. (In ¶ 29, Tran discloses “The first application 108 submits the authentication token 126 to the second application 110 in association with the invocation request, for example, as an HTTP header of the invocation request.”)
Regarding Claim 25, the combination of Tran and Gupta disclose:
The access control system of claim 11, wherein the logic comprises an interface invoking device of the application or execution of an interface invoking operation by the interface invoking device. (In ¶ 29, Tran discloses “The first application 108 invokes the second application 110 by submitting an invocation request to the second application 110.”)
Regarding Claim 26, the combination of Tran and Gupta disclose the limitations of claim 11.
However, Tran does not explicitly disclose a comparison result.
Gupta discloses:
The access control system of claim 11, wherein the access control node is further configured to: receive, from the management node, a comparison result indicating that the first identity feature matches the second identity feature (In ¶ 122, Gupta discloses “Cloud Gate 702 re-directs the user to the SSO microservice and participates in the OIDC “Authorization Code” flow with the SSO microservice. The flow concludes with the delivery of a JWT as an identity token. Cloud Gate 708 validates the JWT (e.g., looks at signature, expiration, destination/audience, etc.) and issues a local session cookie”); and allow the application chain to access the asset based on the comparison result (In ¶ 124, Gupta discloses “When client 708 (e.g., mobile, web apps, JavaScript, etc.) presents an access token (issued by IDCS) to use with a protected REST API 714, Cloud Gate 702 validates the access token before allowing access to the API (e.g., signature, expiration, audience, etc.).”).
One in ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Tran’s approach by utilizing Gupta’s approach of utilizing a management node to perform a comparison as the motivation would be to offload tasks not subject to real-time processing to an asynchronous scheduling mechanism enables the system to provide a high level of service by reducing latencies in response times (See Gupta, ¶ 96)
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Tran, William (US 20180219863), hereinafter referred to as Tran, in view of Gupta et al. (US 20180041515), hereinafter referred to as Gupta, in further view of Radhika, Roy (US 20180357434), hereinafter referred to as Radhika.
Regarding Claim 6, Tran discloses the limitations of claim 1.
However, Tran does not explicitly disclose the use of Bloom filters.
The asset access control method of claim 1, wherein the first identity feature matches the second identity feature when a distance between a first Bloom vector corresponding to the first identity feature and a second Bloom vector corresponding to the second identity feature is less than a preset distance (In ¶ 56 , Radhika discloses “An individual bigram of an identifier is mapped through multiple password-dependent hash functions (keyed-hash message authentication codes (HMACs), such as keyed MD5 or SHA-1) to a Bloom filter... The similarity of two Bloom filters can be computed.” And further in ¶ 65 “The similarity coefficient is often compared with a given threshold that is determined by the performance objective of a given application.”).
One in ordinary skill in the art of cryptography would have been motivated, before the effective filing date of the claimed invention to modify Tran’s approach by utilizing Radhika’s approach of utilizing a bloom filter as the motivation would be to allow for error tolerance when comparing two values rather than specifying an exact match (See Radhika, ¶ 204).
Claim 16 is directed to a system having functionality corresponding to the method of Claims 6, and is rejected by a similar rationale, mutatis mutandis.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Brown et al. (US 20170300872) discloses a system and method for managing transactions in dynamic digital documents.
Kfir et al. (US 20230412389) discloses a method for verifying private data using a synchronization log.
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 SHADI H KOBROSLI whose telephone number is (571)272-1952. The examiner can normally be reached M-F 9am-5pm ET.
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.
/SHADI H KOBROSLI/Examiner, Art Unit 2492 /RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492
Prosecution Insights