DETAILED ACTION
This action is in response to the Request for Continued Examination filed on February 13, 2026. Claims 1, 2, 7, 11, 12, 17, and 20 have been amended, claims 9 and 19 have been canceled and claims 21-22 are new. Claims 1-8, 10-18, 20-22 are pending. Of such, claims 1-8 and 10 represent a method and claims 11-18 and 20-22 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 .
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 February 13, 2026 has been entered.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 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.
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.
Claim(s) 1-5, 10-15, and 20-22 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Tran, William (US 20180219863), hereinafter referred to as Tran.
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 of an 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) and 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.”).
Regarding Claim 2, Tran discloses:
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, Tran discloses:
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, Tran discloses:
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, Tran discloses:
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, Tran discloses:
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 identify 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 of an 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.”).
Regarding Claim 12, Tran discloses:
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; or a resource scheduling device of the application or execution of scheduling a resource by the resource scheduling 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 13, Tran discloses:
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, Tran discloses:
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, Tran discloses:
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, Tran discloses:
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, Tran discloses:
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, Tran discloses:
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.””).
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, 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 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 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.
Claims 7-8 and 17-18 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 7, Tran discloses the limitations of claim 1
However, Tran does not explicitly disclose the concept of two different feature libraries.
Gupta discloses:
The asset access control method of claim 1, further comprising comparing the first identity feature with the second identity feature that is recorded in a local application feature library of the 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 ¶ 51 “Cloud Gate 502 is a component that secures access to multi-tenant IDCS microservices by ensuring that client applications provide valid access tokens, and/or users successfully authenticate in order to establish SSO sessions.” wherein the examiner interprets the cloud cache represents a local library).
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 8, Tran discloses the limitations of claim 1
However, Tran does not explicitly disclose the concept of two different feature libraries.
Gupta discloses:
The asset access control method of claim 7, further comprising updating the local application feature library based on the remote application feature library (In ¶ 48, Gupta discloses “In the embodiment of FIG. 4, an LDAP-based application 218 makes a connection to Cloud Cache 402, and Cloud Cache 402 establishes a connection to IDCS 202 and then pulls data from IDCS 202 as it is being requested.” wherein the examiner interprets the IDCS represents a remote library).
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)
Claims 17-18 are directed to a system having functionality corresponding to the method of Claims 7-8, and are 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.
Cockerill et al. (US 20190141030) discloses a method for cryptographically secure access control for applications using relationships between the applications.
Cao et al. (US 20100250740) discloses a method for comparing generated identifiers to perform a service.
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