Detailed Action
-Claims 1, 10 and 19 are amended.
-Claims 1-20 are pending.
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 Remarks filed on 5/20/2026 have been fully considered.
-The double patenting rejection is withdrawn based on the approved terminal disclaimer filed on 5/20/2026.
-With respect to the 112(b) rejections, the amendments and arguments overcame the existing rejections, however the term “unacceptable” is also indefinite therefore a 112(b) rejection is still applicable as provided below.
-With respect to the argument on page 3 of the Remarks that the resourceHash is not a challenge response, Examiner notes that is argument is moot in view of the new mapping of this feature which is necessitated by the claim amendments. Sole teaches a mutual-TLS as part of the authentication (see at least para.0240-0243) and mutual-TLS includes a challenge-response or handshake protocol which is required for a connection to be established.
-With respect to the argument on page 4 of the Remarks that in Sole the communication is between devices and protected resources, Examiner respectfully disagrees because any device may be considered itself a resource. In addition, Sole paragraphs 0039-0042 describe a communication network that enables data communication between computing devices that are members of the network. For example, business network 110 includes communication network 115, which includes a plurality of devices (e.g., device 125A, device 125N, etc., referred to collectively as “devices 125”), which enables devices 125 to communicate with each other…. Devices 125, 130, 155, and 185 can be any type of computing device, such as a desktop computer, a laptop computer, a file server, a network attached storage (NAS) device, a mobile device, or a server, among others. Therefore the devices in Sole may be servers and they communicate with each other.
-With respect to the argument on pages 4-5 of the Remarks that Sole does not teach reporting of a service request response failure is not persuasive. Sole teaches reporting denied access security events based on telemetry data and a denied access is a service request response failure. The denied access may result from a failed mutual-TLS therefore from a failed/unacceptable transaction response challenge.
-With respect to the argument that Giralte does not teach the amended features, this argument is moot because the office action does not rely on Giralte to teach these features. In addition, Claim 1 only requires “one or both” conditions to fail, and the cited paragraphs teach at least failure in response to an invalid token.
Claim Objections
Claims 10 and 19 are objected because they now recite the terms “determining one or both of that the service ….”. They should be corrected to recite “determining that one or both of
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 10 and 19 recite the terms “unacceptable transaction challenge response” and it is not clear what the scope of “unacceptable” is. For the purpose of examination, “unacceptable” will be interpreted as “invalid”.
The dependent claims inherit these rejections.
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 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Giralte (US Pub.No.2024/0250991) in view of Sole et al (US Pub.No.2021/0392111).
Re Claim 1. Giralte discloses a method comprising: intercepting, at a first policy engine sidecar of a first microservice, a service request from the first microservice to a second microservice, the service request comprising services requested from the second microservice (i.e. first service mesh 207 may include multiple services, such as service 202, and each service may have a sidecar such as sidecar 204. As will be discussed in greater detail below, a service may be configured to perform a specific function within the context of a hosted application, and a sidecar may be configured to handle various communications operations for the service, such as sending and receiving messages and requests…………………a request may be received in a cloud-based computing environment. As discussed above, messages may be sent to and from services within a service mesh of a cloud computing platform. Accordingly, during operation 402, a request may be received at a first sidecar associated with a service within a service mesh. As similarly discussed above, the first sidecar may be communicatively coupled to other services in service meshes, as well as other entities outside of the computing platform) [Giralte, para.0028, 0037]; generating, at the first policy engine sidecar, a transaction challenge; transmitting the service request, a first token [identifying the first microservice], and the transaction challenge to the second microservice (i.e. the first sidecar also modifies the security header with its own verification signature. Accordingly, the first sidecar may include its signature, which may be a private key. In some implementations, the signature may be applied to the result of the verification operation provided by the firewall. In this way, the first sidecar may sign the verification operation provided by the firewall, and the signed verification result may be included in the chain of trust stored in the security header…………. the request may be sent to a second sidecar. Accordingly, once the header has been modified by the first verification entity and the first sidecar, the first sidecar may then send the request to an appropriate downstream entity, such as a second sidecar or a gateway. In some implementations, the appropriate downstream entity may be identified by one or more data values included in the request…………… security header 604 includes an identifier that is configured to identify itself as a security header, and further includes data values representing a status, which may be used to identify safe/not safe or other security identifier. The data values may additionally identify a domain as well as a signature value) [Giralte, para.0040-0041, 0056]; intercepting a service request response from the second microservice to the first microservice (i.e. a sidecar may be configured to handle various communications operations for the service, such as sending and receiving messages and requests………….. if the sidecar determines that the chain of trust included in the security header is valid, the sidecar may forward the request to its target destination which may be its associated service, or may be another entity such as another service or gateway) [Giralte, para.0028, 0035];
Giralte does not explicitly disclose whereas Sole teaches: the first token identifying the first microservice (i.e. A resource can be configured to receive metadata about the authenticated connection to allow for identification of the client and destination. In the case of HTTP backends, this information can be added as extra Headers to the request. For non-HTTP backends, a self-contained custom data structure (described above) can be used and will be prepended before any data is passed. A non-HTTP backend daemon would have to be wrapped with a client that understands this format to be able to use the metadata and discard it before passing control to the daemon. In both cases the connection between the proxy and a backend server needs to be authenticated or inline authentication information must be added (e.g., signed headers)) [Sole, para.0358] the service request response comprising a response in response to the service request transmitted to the second microservice (i.e. Alice tries to execute a command line git operation on her device, which triggers a network communication to the git server “git.fyde.local”…………… The git process opens a new TCP connection to 192.0.2.2 port 9418. The network interception stack replies to it and starts a mutual-TLS connection to the proxy that is protecting this resource………… If the APE decides that access is granted, a Resource Authorization Token is returned granting access to it for a configured amount of time ) [Sole, para.0239-0243]; and transmitting a microservice alert to a central policy server (i.e. if an attacker would succeed in impersonating a device and re-issuing a new certificate for it, the real device would notice immediately that it was denied access and a security event would be filed into the auditing system ………………………Access Policy Engine(APE) continuously re-computes the trust levels of all devices whenever a new (i.e., different from current) piece of telemetry information is reported, keeping the Device-User inventory database always up to date with the latest information collected. In this scheme, a central cluster of APEs can publish updates about trust levels as applied to a given Device and Resource to the Access Proxies controlling such Resources that have recently interacted with such Devices) [Sole, para.0208, 0129, Note: the Access Policy Engine is interpreted as the central policy server] in response to a service request response failure, the service request response failure comprising determining that the service request response comprises one or both of a second token not properly identifying the second microservice and an unacceptable transaction challenge response to the transaction challenge transmitted to the second microservice from the first microservice (i.e. RAP verifies the RAT is valid, not expired, and that the Device ID and Device certificate hash for which it was issued matches the client certificate received………….. The mechanism described in the previous section will only allow access to a resource until the Resource Authorization Token expires, after which the connection will be forcefully terminated) [Sole, para.0246, 0250, Note: it is implied that if the RAT token verification fails, the connection response will be a failure response], (i.e. The ‘resourceHash’ field contains an opaque value that represents the current configuration for a resource from the point of view of a centralized Access Policy Engine. This field allows for deferring requesting updated resource lists in the Resource Access Proxies unless the resourceHash doesn't match or the resourceID is not known to the Proxy………………….if after updating the resource from upstream the hashes still don't match, the connection is denied and token considered invalid) [Sole, para.0209], (i.e. A Resource Access Proxy (RAP) can also be deployed as a sidecar proxy, that is, as a separate process that takes care of handling all networking and transport security for an internal system that delegates all his needs to the proxy) [Sole, para.0131], (i.e. The network interception stack replies to it and starts a mutual-TLS connection to the proxy that is protecting this resource………… If the APE decides that access is granted, a Resource Authorization Token is returned granting access to it for a configured amount of time ) [Sole, para.0240-0243], wherein the microservice alert comprises an identifier of the second microservice and an indication of the service request response failure (i.e. report telemetry events to the Access Policy Engine through an Event Receiver Service that maintains a database of mappings between Device-Users and a custom equipment identifier, along with a data transformation function that converts the event into a common key-value metadata format that can be used by the Access Policy Engine) [Sole, para.0254, Note: since the event data includes a device id, it is implied that the event report includes an indication of the failure event described in para.0209 and the device id].
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify Giralte with Sole because the decoupling between Access Policy and Infrastructure empowers Application Owners to define their own rules according to business needs, without requiring coordination with the infrastructure team [Sole, para.0123].
Re Claims 10 and 19. These claims recite features similar to those in claim 1, therefore they are rejected in a similar manner.
Re Claims 2, 11 and 20. Giralte in view of Sole discloses the features of claims 1, 10 and 19, Sole further discloses: wherein, in response to the service request response failure, the central policy server transmits a notification to each microservice registered with the central policy server that the second microservice is not authorized and/or to remove information about the second microservice (i.e. the APE continuously re-computes the trust levels of all devices whenever a new (i.e., different from current) piece of telemetry information is reported, keeping the Device-User inventory database always up to date with the latest information collected. In this scheme, a central cluster of APEs can publish updates about trust levels as applied to a given Device and Resource to the Access Proxies controlling such Resources that have recently interacted with such Devices) [Sole, para.0129], (i.e. the Fyde cloud will respond that Mallory is not authorized) [Sole, 0417], wherein the first microservice is registered with the central policy server (i.e. an X.509 Device Certificate is created upon enrollment and a compact signed message to relay Access Policy authorization to an Access Proxy. The latter is used to authorize access to resources, either through the RAP or another security broker, and the former is used to identify and authenticate connections ………………… Another point to take into consideration is the inclusion of the ‘latestCertHash’field. This field assures a match between the device certificate used to request the authorization and the one that effectuates the connection to the access proxy) [Sole, para.0136, 0208, also 0141];
Claims 20 further recites: and/or removes registration of the second microservice (i.e. the Fyde cloud will say no, this user was removed or disabled) [Sole, para.0421].
The same motivation to modify with Sole, as in claim 1, applies.
Re Claims 3 and 12. Giralte in view of Sole discloses the features of claims 1 and 10, wherein, in response to the service request response failure, the central policy server removes registration of the second microservice (i.e. suppose that, prior to being fired, Mallory created a rogue proxy with the hopes of being able to trick users like Alice into connecting to the rogue proxy and reading packets at the rogue proxy. The infrastructure used in mTLS requires mutual authentication. When Alice's device connects to a proxy, it both provides its certificate and receives a certificate from the proxy. When Alice enrolled her device, she received a manifest that indicated which proxies she should use. Alice's device will verify information such as that the issuer of the proxy is correct, that the certificate is valid, and that it was issued for the expected tenant. Alice's device will also be able to determine whether it is connected to the correct proxy and not connecting to a different proxy or a malicious proxy…………………...device might have a valid certificate but when the proxy queries the Fyde cloud, the Fyde cloud will say no, this user was removed or disabled) [Sole, para.0418, 0421: Note: it is interpreted then when mTLS fails, the malicious device is removed].
The same motivation to modify with Sole, as in claim 1, applies.
Re Claims 4 and 13. Giralte in view of Sole discloses the features of claims 3 and 12, Sole further discloses: wherein in response to the second microservice registering with the central policy server, the central policy server notifies each registered microservice that the second microservice is registered, wherein the first microservice is registered with the central policy server (i.e. Every time there's a change in the configuration (e.g., a new resource is added), a differential is pushed to the proxy to keep it up to date. So, when a new resource is added (e.g., git), the Fyde Client obtains the configuration and formats it in the particular way that the proxy (e.g., Envoy) needs to receive it, and sends to the proxy so that now it can proxy both IRC and git………………. The Fyde Cloud also includes a policy engine) [Sole, para.0456, 0377].
The same motivation to modify with Sole, as in claim 1, applies.
Re Claims 5 and 14. Giralte in view of Sole discloses the features of claims 1 and 10, wherein transmitting the microservice alert further comprises transmitting the microservice alert in response to determining that the service request response is unresponsive to the service request (i.e. Suppose one of the resources Alice wishes to use requires her to be on premise at ACME (e.g., as determined by Wi-Fi connection). The last time her device contacted the Fyde cloud, she was at home, but she has since arrived at work. When she attempts to access the resource at work, her first attempt might fail if state information associated with her phone is stale (i.e., she may still appear to be not-connected to the appropriate Wi-Fi). Her phone will contact the proxy, the proxy will consult the policy enforcement module, and the policy enforcement module will return, in various embodiments, that (due to information from 25 minutes ago), Alice’s request should be denied because she is not on premises) [Sole, para.0428, Note: it is be interpreted that Alice’s phone is the second microservice and that the response including the state information is unresponsive because it shows as not connected to the appropriate Wi-Fi].
Re Claims 6 and 15. Giralte in view of Sole discloses the features of claims 1 and 10, Sole further discloses: wherein the service request response failure comprises the service request response lacking the second token from the second microservice (i.e. The ‘resourceHash’ field contains an opaque value that represents the current configuration for a resource from the point of view of a centralized Access Policy Engine. This field allows for deferring requesting updated resource lists in the Resource Access Proxies unless the resourceHash doesn't match or the resourceID is not known to the Proxy………………….if after updating the resource from upstream the hashes still don't match, the connection is denied and token considered invalid) [Sole, para.0209].
The same motivation to modify with Sole, as in claim 1, applies.
Re Claims 7 and 16. Giralte in view of Sole discloses the features of claims 1 and 10, Sole further discloses: wherein the service request response failure comprises the service request response lacking a transaction challenge response (i.e. Alice tries to execute a command line git operation on her device, which triggers a network communication to the git server “git.fyde.local”…………… The git process opens a new TCP connection to 192.0.2.2 port 9418. The network interception stack replies to it and starts a mutual-TLS connection to the proxy that is protecting this resource………… If the APE decides that access is granted, a Resource Authorization Token is returned granting access to it for a configured amount of time) [Sole, para.0239-0243, Note: mutual-TLS requires a challenge response, therefore lacking the challenge response will result in a response failure].
The same motivation to modify with Sole, as in claim 1, applies.
Re Claims 8 and 17. Giralte in view of Sole discloses the features of claims 1 and 10, wherein in response to the service request response failure, the first policy engine sidecar ignores communication from the second microservice (i.e. the Fyde cloud will respond that Mallory is not authorized to access any resources, and the proxy can drop the connection) [Sole, para.0417].
The same motivation to modify with Sole, as in claim 1, applies.
Re Claims 9 and 18. Giralte discloses the features of claims 1 and 10, Giralte further discloses: wherein the second microservice comprises a second policy engine sidecar and wherein in response to receiving the service request from the first microservice, the second policy engine sidecar authenticates the first microservice using the first token and information received from a central policy server regarding the first microservice (i.e. During operation 410, the second sidecar may perform a DNS lookup of the domain of the first sidecar to verify that the domain of the first sidecar is a trusted domain…. the second sidecar may use a DNS query to retrieve a public key from the domain, and the public key may be used to verify the signature included in the security header. In this way, the second sidecar may verify that the domain of the security header is a trusted domain, and that the signature included in the security header is valid for that domain. In some implementations, trusted domains may be identified based on a designated list of trusted domains that may have been determined by an entity, such as an on-demand service provider. Accordingly, the on-demand service provider may have previously generated a list based on observed traffic to the sidecar and known domains its associated service interacts with to execute an application) [Giralte, para.0042-0043] and/or the second policy engine sidecar generates the transaction challenge response in response to authenticating the first microservice using the first token, the transaction challenge response comprising transaction details corresponding to the authentication of the first microservice by the second policy engine sidecar.
Conclusion
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 NOURA ZOUBAIR whose telephone number is (571)270-7285. The examiner can normally be reached Monday - Friday.
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, Ali Shayanfar can be reached at 571-270-1050. 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.
/NOURA ZOUBAIR/Primary Examiner, Art Unit 2434
Prosecution Insights