Detailed Action
Claims 1-20 are presented for examination.
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 .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of copending Application No. 18/772611. Although the claims at issue are not identical, they are not patentably distinct from each other because the claims in the copending application in view of Sole render obvious the claims in the current application. The same motivation to modify with Sole as presented in claim 1 is applicable.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
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 “intercepting a service request from the first microservice to a second microservice” and also recite “intercepting a service request response from a second microservice to the first microservice”. It is not clear if the two recitations are referring to a same or different second microservice, also subsequent recitations of “the second microservice” are indefinite. For the purpose of examination, the first and second recitations are interpreted as referring to different microservices.
Claims 1, 10 and 19 recite the terms “acceptable transaction challenge response” and it is not clear what the scope of “acceptable” is. For the purpose of examination, “acceptable” will be interpreted as “valid”.
The dependent claims inherit these rejections.
Claims 2, 9, 11, 18 and 20 recite “and/or” and it is not clear whether the subsequent limitations are required or not. For the purpose of examination, the claims are interpreted as reciting “or”.
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 a 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], 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 a failure in determining that the service request response comprises a second token properly identifying the second microservice and an acceptable transaction challenge 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 this needs to the proxy) [Sole, para.0131], 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. 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 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.
Prior art made of record however not relied upon includes:
Coffing (US Pub.No.2022/0224535) describes network environment 100 in which systems for microservices-based authorization and access management may be implemented. As illustrated, an exemplary system may include an identity-as-a-service (“IDaaS”) server 110, a security plane 120, an API gateway 130, and one or more service pods 140 that deploy microservices. In the embodiment illustrated, the service pod(s) 140 include a service A pod 140A and a service B pod 140B. Each service pod 140 may further each include a proxy 150, a security sidecar 160, and a respective code or application 170 for providing a respective service [0019].
Conclusion
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