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, see page 7, filed on 04/08/2026, with respect to claims 10, 11, and 14 have been fully considered and are persuasive. The rejection of10, 11 and 14 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 has been withdrawn.
The examiner fully considered the applicant’s argument remarks filed on 04/08/2026 in response to the Office action mailed on 01/08/2026, however the following applicant’s argument are not persuasive to overcome the following applicant’s argument remarks. The applicant argument stats that applicant's technique as recited in Claim 1 is not merely about creating a "certification token" in the abstract: it pertains to a specific method for establishing a certification token for an instantiation of a node cluster as a whole. This token serves as a certificate that guarantees the various components involved in such a cluster (master node, compute nodes, containers) comply with pre-defined technical and/or contractual constraints. The applicant states, this cluster-wide certification token is generated by a central certification server based on a collection of individual certificates: a first instantiation certificate from the master node and at least one second instantiation certificate from a container of a compute node. The certification token generated in this way provides a comprehensive guarantee regarding the cluster's configuration. By contrast, Nainar does not teach or suggest a token that certifies "an instantiation of a node cluster" (entire cluster including not only containers of the compute node, but also the master node). Nainar "attestation token" is used to verify the integrity of an individual podat a specific moment in time to establish an "integrity verified path". The purpose is to ensure a specific endpoint is not compromised, and not to certify that the entire cluster's configuration (hardware, software, location, etc.) meets predefined criteria. In this respect, Nainar does not teach or suggest the limitation of Claim 1 according to which the master node "establishres] a first instantiation certificate of said master node by means of a first set of certification parameters requested from a certification server".
The examiner respectfully disagrees with the above applicant’s assertions and argument. First, limitations of claim 1 does not assert or recite the certification to token is a cluster-wide certification to configure the whole cluster or for the entire cluster's configuration. Features or limitation in the application’s specification are not assertively brought into claim 1. Furthermore, under BRI, the examiner notes that instantiation of a cluster node is comprising a master node, a compute node and a container rather than the entire cluster's configuration.
Second, the prior art Nainar, discloses the above argued features or limitations in [0013] the configurations that includes receiving, by a first network service mesh (NSM) from a first pod of a first node, a first request to instantiate a first integrity verified path to a first network service endpoint (NSE) pod of a second node. Generating, by the first pod, the first attestation token, receiving, by the first NSM from the first pod, the first attestation token, and verifying, by the first NSM, the first attestation token with a certificate authority (CA) server. [0019] The local NSM receiving the request for an integrity verified path from the requesting pod may request the attestation token from the NSE pod. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod. When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server. Once the validation is a success, the NSM may instantiate the integrity verified path between the requesting pod and the NSE pod and inject the integrity verified path into the requesting pod.
The applicant continues to argue that “Nainar never teaches any kind of certificate that would be established for a master node.” The examiner disagrees with the applicant’s argument because Nainar discloses in [0013] the attestation token is verified by the NSM with a certificate authority (CA) server.
The applicant continues to argue that the "Network Service Mesh (NSM)" of NAINAR cannot be assimilated to a master node as recited: all the figures of Nainar clearly show that a NSM is part of a worker (i.e., a compute) node, and not of the master node which is also shown on the figures. Besides, Nainar never teaches nor suggests establishing a certificate for an NSM.
The examiner disagrees with the applicant’s assertion. Unlike the applicant’s argument because the prior art Nainar discloses a master node and at least one compute node reading on the following features “([0024] a portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform. The portion 102 includes a master node 104 and two worker nodes 106a, 106b. As is known, the portion 102 may include many more worker nodes 106. The master node 104 includes an API-server 108 a. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108. The worker node 106a includes a pod 112, which is a grouping of one or more containers (not illustrated) that provide services. The worker node 106a may include many more pods 112. The worker node 106b includes a network service endpoint (NSE) pod 114, which is a grouping of one or more containers (not illustrated)……. [0025] In configurations, when a pod, e.g., pod 112, wishes to obtain a service from another pod, the pod 112 may request an integrity verified path, e.g., the integrity verified path 116, to the NSE pod, e.g., the NSE pod 114, by sending a request for an integrity verified path to the local NSM, e.g., the NSM 110a. The request for the integrity verified path 116 that is sent to the NSM 110a may include various attributes.
Based on the above description, the applicant’s argument are not persuasive to overcome the prior arts in record and place claim 1 in a better condition for allowance. According to the applicant’s assertion, independent claims 9, 10, 11, 12 and 14 are having substantially similar limitations to claim 1. Therefore, claims 9, 10, 11, 12 and 14 remain rejected for the same reaons presented above for claim 1.
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-12 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Nainar et al. (US 20220103570 A1 –hereinafter –“Nainar”) in view of HASHMI et al. (US 20210157896 A1 –hereinafter—" SRIVASTAVA”).
As per claim 1: Nainar discloses a method of obtaining a token of an instantiation of a node cluster ([0016] In configurations, an attestation token may allow for providing a unidirectional integrity check within a cluster of nodes, or between nodes of different clusters) comprising
a master node and at least one compute node ([0024] a portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform. The portion 102 includes a master node 104 and two worker nodes 106a, 106b. As is known, the portion 102 may include many more worker nodes 106. The master node 104 includes an API-server 108 a. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108) comprising
at least one container intended to perform at least one task ([0006] FIGS. 1A, 1B, and 1C a portion of a container-orchestration system configured in accordance with the Kubernetes platform),
said method comprising the following implemented by said master node (0014: Verifying, by the first NSM, the second attestation token with the certificate authority (CA) server, wherein instantiating the first integrity verified path between the first pod and the first NSE pod is further based at least in part on the verifying the third attestation token with the CA server):
establishing a first instantiation certificate of said master node by means of a first set of certification parameters requested from a certification server ([0024] The master node 104 includes an API-server 108. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108. The worker node 106a includes a pod 112, which is a grouping of one or more containers (not illustrated) that provide services. The worker node 106a may include many more pods 112. The worker node 106b includes a network service endpoint (NSE) pod 114, which is a grouping of one or more containers (not illustrated)……. [0025] In configurations, when a pod, e.g., pod 112, wishes to obtain a service from another pod, the pod 112 may request an integrity verified path, e.g., the integrity verified path 116, to the NSE pod, e.g., the NSE pod 114, by sending a request for an integrity verified path to the local NSM, e.g., the NSM 110a. The request for the integrity verified path 116 that is sent to the NSM 110a may include various attributes);
obtaining at least one second instantiation certificate for said container of said compute node ([0019] various protocols are extended to request and send attestation tokens (such as address resolution protocol (ARP), bi-directional forwarding (BFD), control protocols, etc.). The techniques described herein leverage these protocols and let the network service mesh (NSM) query different entities that are involved at the control plane and data plane layer for the integrity verified path instantiation. The local NSM receiving the request for an integrity verified path from the requesting pod may request the attestation token from the NSE pod. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod. When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server. Once the validation is a success, the NSM may instantiate the integrity verified path between the requesting pod and the NSE pod and inject the integrity verified path into the requesting pod);
said second certificate being established by said compute node by means of at least one second set of certification parameters requested from the certification server ([0026]The request may include a second locally generated nonce generated by the NSM 110a. The NSE pod 114 may generate the second attestation token using the second nonce and provide the second attestation token to the NSM 110a. The NSM 110a may have the attestation token verified by the CA server 120, thereby confirming the integrity of the NSE pod 114. Since the attestation tokens verify the integrity of the pods 112, 114, the NSM 110a may instantiate the integrity verified path 116 between the pod 112 and the NSE pod 114 and inject the integrity verified path 116 into the pod 112);
transmitting, to said certification server, a request for generating said token of an instantiation of the node cluster, said request comprising said first certificate and said at least one second certificate ([0013] When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server); and
receiving said token of an instantiation of the node cluster generated by the certification server([0013] generating, by the first pod, the first attestation token, receiving, by the first NSM from the first pod, the first attestation token, and verifying, by the first NSM, the first attestation token with a certificate authority (CA) server. The method may additionally include providing, by the first NSM to the first NSE pod, a third request for a second attestation token, the third request including a second randomly generated nonce and receiving, by the first NSM from the first NSE pod, the second attestation token, the second attestation token being based at least in part on the second randomly generated nonce. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod).
Nainar does not explicitly disclose the establishing token is a certification token. HASHMI, in analogous art however, discloses the establishing token is a certification token ([0098] At Step 3, the sidecar 514 may be implemented to use the application identity token 522 to broker an identity token with enterprise scope 524. In an exemplary embodiment, the pod 510 is provided with a platform internal token 516. In an exemplary embodiment, the platform internal token 516 is a JWT. In another exemplary embodiment, the platform internal identity token 516 is in the form of at least one X.509 certificate. The platform internal token 516 is a signed token which identifies the bearer to a party which trusts the issuer. The platform internal token 516 may be directly or indirectly connected to an API Server 518. A keys API 520 may be provided with the platform internal token 516. The keys API 520 may include or be related to a chain of trust. [0099] In Step 4A, application tokens database 506 may receive or accept an application identity token 522 from Identity Helper Sidecar 514. In an exemplary embodiment, the application identity token 522 is a JWT. In Step 4B, application tokens database 506 may communicate information to Keys API 520. Application tokens database may have a cache which may include a Keys API URL for every cluster. The Keys API URL may be Secure Socket Layer (SSL) enabled with a certificate in the chain of trust. In Step 4C, application tokens database 506 may transmit an identity token with enterprise scope 524 to the Identity Helper Sidecar 514. A micro-service may be created to expose the public key that was used to sign the application identity token 522. Application tokens database 506 may have a certificate in a chain of trust. An SSL connection may be used in Steps 4A through 4C. The SSL connection that may be used in Steps 4A through 4C may use a certificate in the chain of trust. In Step 5, information may be determined by the Identity Helper Sidecar 514. The information determined by the Identity Helper Sidecar 514 may be used by Pod 510. [0100] Referring to FIG. 6, a second data flow diagram 600 is shown. According to an exemplary embodiment, Steps in validating an application identity token 522 are presented. A cluster 502 may include a certificate service 608, an application identity token 522, and an identity token with enterprise scope 524. The cluster 502 may be a Kubernetes cluster or any platform which supports a running instance of an application. The cluster 502 may be configured to communicate with application tokens database 506. Application tokens database 506 may be configured to communicate with application-specific data repository 504. The cluster 502 may create an entry in application-specific data repository 504 for the application identification and cluster combination. Application tokens database 506 may verify the application component and cluster combination before returning the identity token with enterprise scope 524).
HASHMI further discloses ([0104-0105] Referring to FIG. 7, a third data flow diagram 700 is shown. According to an exemplary embodiment, a cluster 502 (e.g., Kubemetes cluster or any platform which supports a running instance of an application) may be in communication with application-specific data repository 504. In an exemplary embodiment, the cluster 502 publishes a public key endpoint URL to application-specific data repository 504. The cluster 502 may include a cluster Certificate Authority (CA) 704 that is configured to issue a plurality of certificates, including, but not limited to, a controller-manager certificate 706, an API-server certificate 708, and a service-account certificate 710. There may be relevant API Server Parameters. For example, relevant API Server Parameters may include, but are not limited to, a service account key file, a service account signing key file, a service account issuer, and a service account API audience. The service account key file may relate to a private key used to sign a service account application identity token. The service account signing key file may relate to a public key used to sign a service account application identity token. The service account issuer may relate to an issuer attribute in the certificate used to sign the application identity token. The service account API audience may relate to at least one service account token that may be transmitted via a projected volume method. The at least one service account token may have a tag with a specified audience value). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by Nainar to include the establishing token is a certification token. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to facilitate an identification of an application that runs on a platform by establishing the identity of the applications that run on the platform and making the identity available, for example, to application containers, nodes, workers, minions, or machines where workloads are deployed such that the applications can seamlessly connect to other services without the need for authentication such as passwords as suggested by HASHMI ([0005]).
As per claim 2: Nainar in view of HASHMI discloses the method of obtaining a certification token according to claim 1, wherein the sets of certification parameters requested from the certification server comprise at least one item of timestamping information and one hash of an identifier of said certification server (HASHMI [0089] According to an exemplary embodiment, at least one of the platform-local identity token, the token describing the application owner, and the enterprise token describing the identity of the application is a time-limited token, i.e., is a token that is valid for a predetermined amount of time. Tune-limited tokens may be replaced with another token. When a token has expired or when a token is soon to expire, an automated process may replace an expired or soon-to-be expired token. A process for replacing a token may be similar to the automated process that originally issued the token. [0093] The scope may include information relating to two or more parties. An application identity token 522 may include information such as, for example, an issuer (i.e., the cluster from which the application identity token 522 is issued), an expiration time (i.e., when the token expires), an issuance time (i.e., when the token was issued), a name space, a secret name, a service account name, a service account unique identifier (UID), and a pod name).
As per claim 3: Nainar in view of HASHMI discloses the method of obtaining a certification token according to claim 2, wherein the requested sets of certification parameters also include an item of location information (HASHMI [0041] The computer system 102 may also include at least one input device 110, such as a keyboard, a touch-sensitive input screen or pad, a speech input, a mouse, a remote control device having a wireless keypad, a microphone coupled to a speech recognition engine, a camera such as a video camera or still camera, a cursor control device, a global positioning system (GPS) device, an altimeter, a gyroscope, an accelerometer, a proximity sensor, or any combination thereof. Those skilled in the art appreciate that various embodiments of the computer system 102 may include multiple input devices 110. Moreover, those skilled in the art further appreciate that the above-listed, exemplary input devices 110 are not meant to be exhaustive and that the computer system 102 may include any additional, or alternative, input devices 110).
As per claim 4: Nainar in view of HASHMI discloses the method of obtaining a certification token according to claim 2, wherein the requested sets of certification parameters are signed by means of a private cryptographic key of the certification server (HASHMI [0092] Even though a cloud platform may have a trusted place in the infrastructure, the cloud platform's identity may be verified by the Kerberos infrastructure for each request. In an exemplary embodiment, the Kerberos infrastructure may verify the identity of the platform based on each entity or deployment of the cloud infrastructure, which may be registered in a central application registry. Any token that the cloud platform presents to the Kerberos infrastructure may be signed using the platform's private key. The corresponding public key may be retrieved from an endpoint that is looked up in the central application registry).
As per claim 5: Nainar in view of HASHMI discloses the method of obtaining a certification token according to claim 1, wherein the first certificate is also established from data relating to said master node and belonging to a group comprising: a network address of the master node; a physical address of the master node; at least one identifier of a model of the hardware constituting the master node; at least one identifier of at least one software executed by the master node; an identifier of an operator orchestrating said node cluster; at least one identifier of at least one task performed by at least one container of at least one compute node of said cluster; an identifier of at least one service provider on behalf of which a container performs a task; and a hash of at least one of the above data (HASHMI: [0010] At least one of the platform-local identity token and the enterprise token describing the identity of the application may include at least one of an application identifier, a platform instance identifier, and a platform tenant space identifier. [0081] At step S412, the PAI module 302 issues a platform-local identity token to the instance of the application. In an exemplary embodiment, the PAI module 302 issues the application instance with the platform-local identity token. According to an exemplary embodiment, the platform-local identity token may be time-limited and/or may include at least one of an application identifier, a platform instance identifier, and a platform tenant space identifier. In an exemplary embodiment, the platform may issue the application instance with a platform-local identity token and the application may initially use the platform-local identity token to authenticate a request to an “identity provider” running in the platform's context for the platform to issue a token that describes the application owner. [0093] An application identity token 522 may include information such as, for example, an issuer (i.e., the cluster from which the application identity token 522 is issued), an expiration time (i.e., when the token expires), an issuance time (i.e., when the token was issued), a name space, a secret name, a service account name, a service account unique identifier (UID), and a pod name).
As per claim 6: Nainar in view of HASHMI discloses the method of obtaining a certification token according to claim 1, wherein the certification token comprises at least one hash of the first certificate and the second certificate timestamped by the certification server (HASHMI [0099]: The Keys API URL may be Secure Socket Layer (SSL) enabled with a certificate in the chain of trust. In Step 4C, application tokens database 506 may transmit an identity token with enterprise scope 524 to the Identity Helper Sidecar 514. A micro-service may be created to expose the public key that was used to sign the application identity token 522. Application tokens database 506 may have a certificate in a chain of trust. An SSL connection may be used in Steps 4A through 4C. The SSL connection that may be used in Steps 4A through 4C may use a certificate in the chain of trust. In Step 5, information may be determined by the Identity Helper Sidecar 514. The information determined by the Identity Helper Sidecar 514 may be used by Pod 510).
As per claim 7: Nainar in view of HASHMI discloses the method of obtaining a certification token according to claim 6, wherein the certification token is signed by means of the private cryptographic key of the certification server (HASHMI [0105] The Keys API URL may be Secure Socket Layer (SSL) enabled with a certificate in the chain of trust. In Step 4C, application tokens database 506 may transmit an identity token with enterprise scope 524 to the Identity Helper Sidecar 514. A micro-service may be created to expose the public key that was used to sign the application identity token 522. Application tokens database 506 may have a certificate in a chain of trust. An SSL connection may be used in Steps 4A through 4C. The SSL connection that may be used in Steps 4A through 4C may use a certificate in the chain of trust. In Step 5, information may be determined by the Identity Helper Sidecar 514. The information determined by the Identity Helper Sidecar 514 may be used by Pod 510).
As per claim 8: Nainar discloses a method of establishing a token for an instantiation of a node cluster comprising ([0016] In configurations, an attestation token may allow for providing a unidirectional integrity check within a cluster of nodes, or between nodes of different clusters) a master node and at least one compute node ( [0024] a portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform. The portion 102 includes a master node 104 and two worker nodes 106a, 106b. As is known, the portion 102 may include many more worker nodes 106. The master node 104 includes an API-server 108 a. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108) comprising
at least one container intended to execute at least one task ([0006] FIGS. 1A, 1B, and 1C a portion of a container-orchestration system configured in accordance with the Kubernetes platform), said method comprising the following steps implemented by a certification server (0014: Verifying, by the first NSM, the second attestation token with the certificate authority (CA) server, wherein instantiating the first integrity verified path between the first pod and the first NSE pod is further based at least in part on the verifying the third attestation token with the CA server):
transmitting of a first set of certification parameters to said master node ([0024] The master node 104 includes an API-server 108. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108. The worker node 106a includes a pod 112, which is a grouping of one or more containers (not illustrated) that provide services. The worker node 106a may include many more pods 112. The worker node 106b includes a network service endpoint (NSE) pod 114, which is a grouping of one or more containers (not illustrated)……. [0025] In configurations, when a pod, e.g., pod 112, wishes to obtain a service from another pod, the pod 112 may request an integrity verified path, e.g., the integrity verified path 116, to the NSE pod, e.g., the NSE pod 114, by sending a request for an integrity verified path to the local NSM, e.g., the NSM 110a. The request for the integrity verified path 116 that is sent to the NSM 110a may include various attributes);
transmitting at least one second set of certification parameters to at least one container of said compute node ([0019] various protocols are extended to request and send attestation tokens (such as address resolution protocol (ARP), bi-directional forwarding (BFD), control protocols, etc.). The techniques described herein leverage these protocols and let the network service mesh (NSM) query different entities that are involved at the control plane and data plane layer for the integrity verified path instantiation. The local NSM receiving the request for an integrity verified path from the requesting pod may request the attestation token from the NSE pod. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod. When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server. Once the validation is a success, the NSM may instantiate the integrity verified path between the requesting pod and the NSE pod and inject the integrity verified path into the requesting pod);
receiving, from said master node, a request for generating said token of an instantiation of the node cluster ([0021] In configurations, the NSM may contain a table of integrity verified endpoints, e.g., pods. Thus, when a request is made for an integrity verified path to a particular NSE pod, the NSM may check the table and determine if the requesting pod and/or the NSE pod are already verified, the NSM may instantiate the integrity verified path between the requesting pod and the NSE pod. In order to maintain the integrity of the various pods, the NSM interface may periodically re-validate pods within the table. The re-validation may include providing a locally generated nonce, sending it to the pod with a request for an attestation token, and then verifying the attestation token received from the pod with the CA server. A re-validation interval may define a periodic/continuous re-validation time interval), said request comprising
a first instantiation certificate of said master node established by means of the first set of certification parameters ([0021] The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114) and
at least one second instantiation certificate of said container established by means of the second set of certification parameters ([0026]The request may include a second locally generated nonce generated by the NSM 110a. The NSE pod 114 may generate the second attestation token using the second nonce and provide the second attestation token to the NSM 110a. The NSM 110a may have the attestation token verified by the CA server 120, thereby confirming the integrity of the NSE pod 114. Since the attestation tokens verify the integrity of the pods 112, 114, the NSM 110a may instantiate the integrity verified path 116 between the pod 112 and the NSE pod 114 and inject the integrity verified path 116 into the pod 112);
generating said token of an instantiation of the node cluster by means of said first certificate and said at least one second certificate ([0013] generating, by the first pod, the first attestation token, receiving, by the first NSM from the first pod, the first attestation token, and verifying, by the first NSM, the first attestation token with a certificate authority (CA) server. The method may additionally include providing, by the first NSM to the first NSE pod, a third request for a second attestation token, the third request including a second randomly generated nonce and receiving, by the first NSM from the first NSE pod, the second attestation token, the second attestation token being based at least in part on the second randomly generated nonce. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod); and
transmitting said token of an instantiation of the node cluster to said master node ([0013] When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server).
Nainar does not explicitly disclose the establishing token is a certification token. HASHMI, in analogous art however, discloses the establishing token is a certification token ([0098] At Step 3, the sidecar 514 may be implemented to use the application identity token 522 to broker an identity token with enterprise scope 524. In an exemplary embodiment, the pod 510 is provided with a platform internal token 516. In an exemplary embodiment, the platform internal token 516 is a JWT. In another exemplary embodiment, the platform internal identity token 516 is in the form of at least one X.509 certificate. The platform internal token 516 is a signed token which identifies the bearer to a party which trusts the issuer. The platform internal token 516 may be directly or indirectly connected to an API Server 518. A keys API 520 may be provided with the platform internal token 516. The keys API 520 may include or be related to a chain of trust. [0099] In Step 4A, application tokens database 506 may receive or accept an application identity token 522 from Identity Helper Sidecar 514. In an exemplary embodiment, the application identity token 522 is a JWT. In Step 4B, application tokens database 506 may communicate information to Keys API 520. Application tokens database may have a cache which may include a Keys API URL for every cluster. The Keys API URL may be Secure Socket Layer (SSL) enabled with a certificate in the chain of trust. In Step 4C, application tokens database 506 may transmit an identity token with enterprise scope 524 to the Identity Helper Sidecar 514. A micro-service may be created to expose the public key that was used to sign the application identity token 522. Application tokens database 506 may have a certificate in a chain of trust. An SSL connection may be used in Steps 4A through 4C. The SSL connection that may be used in Steps 4A through 4C may use a certificate in the chain of trust. In Step 5, information may be determined by the Identity Helper Sidecar 514. The information determined by the Identity Helper Sidecar 514 may be used by Pod 510. [0100] Referring to FIG. 6, a second data flow diagram 600 is shown. According to an exemplary embodiment, Steps in validating an application identity token 522 are presented. A cluster 502 may include a certificate service 608, an application identity token 522, and an identity token with enterprise scope 524. The cluster 502 may be a Kubernetes cluster or any platform which supports a running instance of an application. The cluster 502 may be configured to communicate with application tokens database 506. Application tokens database 506 may be configured to communicate with application-specific data repository 504. The cluster 502 may create an entry in application-specific data repository 504 for the application identification and cluster combination. Application tokens database 506 may verify the application component and cluster combination before returning the identity token with enterprise scope 524.
HASHMI further discloses ([0104-0105] Referring to FIG. 7, a third data flow diagram 700 is shown. According to an exemplary embodiment, a cluster 502 (e.g., Kubemetes cluster or any platform which supports a running instance of an application) may be in communication with application-specific data repository 504. In an exemplary embodiment, the cluster 502 publishes a public key endpoint URL to application-specific data repository 504. The cluster 502 may include a cluster Certificate Authority (CA) 704 that is configured to issue a plurality of certificates, including, but not limited to, a controller-manager certificate 706, an API-server certificate 708, and a service-account certificate 710. There may be relevant API Server Parameters. For example, relevant API Server Parameters may include, but are not limited to, a service account key file, a service account signing key file, a service account issuer, and a service account API audience. The service account key file may relate to a private key used to sign a service account application identity token. The service account signing key file may relate to a public key used to sign a service account application identity token. The service account issuer may relate to an issuer attribute in the certificate used to sign the application identity token. The service account API audience may relate to at least one service account token that may be transmitted via a projected volume method. The at least one service account token may have a tag with a specified audience value). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by Nainar to include the establishing token is a certification token. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to facilitate an identification of an application that runs on a platform by establishing the identity of the applications that run on the platform and making the identity available, for example, to application containers, nodes, workers, minions, or machines where workloads are deployed such that the applications can seamlessly connect to other services without the need for authentication such as passwords as suggested by HASHMI ([0005]).
As per claim 9: Nainar discloses a method of establishing a certificate of an instantiation intended to execute at least one task ([0006] FIGS. 1A, 1B, and 1C a portion of a container-orchestration system configured in accordance with the Kubernetes platform), said container belonging to a compute node of a node cluster ([0016] In configurations, an attestation token may allow for providing a unidirectional integrity check within a cluster of nodes, or between nodes of different clusters) comprising
a master node and a plurality of compute nodes ([0024] a portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform. The portion 102 includes a master node 104 and two worker nodes 106a, 106b. As is known, the portion 102 may include many more worker nodes 106. The master node 104 includes an API-server 108 a. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108),
said method comprising the following implemented by a container (0014: Verifying, by the first NSM, the second attestation token with the certificate authority (CA) server, wherein instantiating the first integrity verified path between the first pod and the first NSE pod is further based at least in part on the verifying the third attestation token with the CA server):
establishing a certificate instantiation by means of a set of certification parameters requested from a certification server([0024] The master node 104 includes an API-server 108. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108. The worker node 106a includes a pod 112, which is a grouping of one or more containers (not illustrated) that provide services. The worker node 106a may include many more pods 112. The worker node 106b includes a network service endpoint (NSE) pod 114, which is a grouping of one or more containers (not illustrated)……. [0025] In configurations, when a pod, e.g., pod 112, wishes to obtain a service from another pod, the pod 112 may request an integrity verified path, e.g., the integrity verified path 116, to the NSE pod, e.g., the NSE pod 114, by sending a request for an integrity verified path to the local NSM, e.g., the NSM 110a. The request for the integrity verified path 116 that is sent to the NSM 110a may include various attributes); and
transmitting, to said master node, said certificate ([0013] When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server).
Nainar does not explicitly disclose said instantiation is an instantiation of at least one container. HASHMI, in analogous art however, discloses said instantiation is an instantiation of at least one container ([0104-0105] Referring to FIG. 7, a third data flow diagram 700 is shown. According to an exemplary embodiment, a cluster 502 (e.g., Kubemetes cluster or any platform which supports a running instance of an application) may be in communication with application-specific data repository 504. In an exemplary embodiment, the cluster 502 publishes a public key endpoint URL to application-specific data repository 504. The cluster 502 may include a cluster Certificate Authority (CA) 704 that is configured to issue a plurality of certificates, including, but not limited to, a controller-manager certificate 706, an API-server certificate 708, and a service-account certificate 710. There may be relevant API Server Parameters. For example, relevant API Server Parameters may include, but are not limited to, a service account key file, a service account signing key file, a service account issuer, and a service account API audience. The service account key file may relate to a private key used to sign a service account application identity token. The service account signing key file may relate to a public key used to sign a service account application identity token. The service account issuer may relate to an issuer attribute in the certificate used to sign the application identity token. The service account API audience may relate to at least one service account token that may be transmitted via a projected volume method. The at least one service account token may have a tag with a specified audience value). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by Nainar to include said instantiation is an instantiation of at least one container. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to facilitate an identification of an application that runs on a platform by establishing the identity of the applications that run on the platform and making the identity available, for example, to application containers, nodes, workers, minions, or machines where workloads are deployed such that the applications can seamlessly connect to other services without the need for authentication such as passwords as suggested by HASHMI ([0005]).
As per claim 10: Nainar discloses a method of verifying a authenticity of a token of an instantiation of a node cluster comprising ([0016] In configurations, an attestation token may allow for providing a unidirectional integrity check within a cluster of nodes, or between nodes of different clusters)
a master node and at least one compute node ([0024] a portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform. The portion 102 includes a master node 104 and two worker nodes 106a, 106b. As is known, the portion 102 may include many more worker nodes 106. The master node 104 includes an API-server 108 a. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108) comprising
at least one container intended to execute at least one task ([0006] FIGS. 1A, 1B, and 1C a portion of a container-orchestration system configured in accordance with the Kubernetes platform),
said method comprising the following steps implemented by an item of equipment to access a service implemented by said node cluster (0014: Verifying, by the first NSM, the second attestation token with the certificate authority (CA) server, wherein instantiating the first integrity verified path between the first pod and the first NSE pod is further based at least in part on the verifying the third attestation token with the CA server):
transmitting, to said master node, a request for establishing a session with said node cluster ([0019] The local NSM receiving the request for an integrity verified path from the requesting pod may request the attestation token from the NSE pod. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod. When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server);
receiving a signalling message relating to the establishment of said session ([0025] The request for the integrity verified path 116 that is sent to the NSM 110a may include various attributes. For example, the request may include attributes such as, for example, a label (e.g., conditions for selecting a NSE for providing a desired service), a network service (e.g., the type of desired service), and a color (e.g., quality of service). In configurations, the request may also include integrity attributes including integrity-verified (an indication if the node that includes the NSE pod should be integrity verified) and continuous (an indication if the node that includes the NSE pod needs to only initially be integrity verified or if the node should be periodically re-validated for integrity, e.g., the node should be continuously integrity verified) further comprising
said token established by a certification server by means of a first instantiation certificate of said master node established by means of a first set of certification parameters requested from the certification server ([0024] The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114) ; and
at least one second instantiation certificate of said container established by means of a second set of certification parameters requested from the certification server([0026]The request may include a second locally generated nonce generated by the NSM 110a. The NSE pod 114 may generate the second attestation token using the second nonce and provide the second attestation token to the NSM 110a. The NSM 110a may have the attestation token verified by the CA server 120, thereby confirming the integrity of the NSE pod 114. Since the attestation tokens verify the integrity of the pods 112, 114, the NSM 110a may instantiate the integrity verified path 116 between the pod 112 and the NSE pod 114 and inject the integrity verified path 116 into the pod 112); and
verifying the authenticity of said token with said certification server ([0013] generating, by the first pod, the first attestation token, receiving, by the first NSM from the first pod, the first attestation token, and verifying, by the first NSM, the first attestation token with a certificate authority (CA) server. The method may additionally include providing, by the first NSM to the first NSE pod, a third request for a second attestation token, the third request including a second randomly generated nonce and receiving, by the first NSM from the first NSE pod, the second attestation token, the second attestation token being based at least in part on the second randomly generated nonce. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod).
Nainar does not explicitly disclose the establishing token is a certification token. HASHMI, in analogous art however, discloses the establishing token is a certification token ([0098] At Step 3, the sidecar 514 may be implemented to use the application identity token 522 to broker an identity token with enterprise scope 524. In an exemplary embodiment, the pod 510 is provided with a platform internal token 516. In an exemplary embodiment, the platform internal token 516 is a JWT. In another exemplary embodiment, the platform internal identity token 516 is in the form of at least one X.509 certificate. The platform internal token 516 is a signed token which identifies the bearer to a party which trusts the issuer. The platform internal token 516 may be directly or indirectly connected to an API Server 518. A keys API 520 may be provided with the platform internal token 516. The keys API 520 may include or be related to a chain of trust. [0099] In Step 4A, application tokens database 506 may receive or accept an application identity token 522 from Identity Helper Sidecar 514. In an exemplary embodiment, the application identity token 522 is a JWT. In Step 4B, application tokens database 506 may communicate information to Keys API 520. Application tokens database may have a cache which may include a Keys API URL for every cluster. The Keys API URL may be Secure Socket Layer (SSL) enabled with a certificate in the chain of trust. In Step 4C, application tokens database 506 may transmit an identity token with enterprise scope 524 to the Identity Helper Sidecar 514. A micro-service may be created to expose the public key that was used to sign the application identity token 522. Application tokens database 506 may have a certificate in a chain of trust. An SSL connection may be used in Steps 4A through 4C. The SSL connection that may be used in Steps 4A through 4C may use a certificate in the chain of trust. In Step 5, information may be determined by the Identity Helper Sidecar 514. The information determined by the Identity Helper Sidecar 514 may be used by Pod 510. [0100] Referring to FIG. 6, a second data flow diagram 600 is shown. According to an exemplary embodiment, Steps in validating an application identity token 522 are presented. A cluster 502 may include a certificate service 608, an application identity token 522, and an identity token with enterprise scope 524. The cluster 502 may be a Kubernetes cluster or any platform which supports a running instance of an application. The cluster 502 may be configured to communicate with application tokens database 506. Application tokens database 506 may be configured to communicate with application-specific data repository 504. The cluster 502 may create an entry in application-specific data repository 504 for the application identification and cluster combination. Application tokens database 506 may verify the application component and cluster combination before returning the identity token with enterprise scope 524.
HASHMI further discloses ([0104-0105] Referring to FIG. 7, a third data flow diagram 700 is shown. According to an exemplary embodiment, a cluster 502 (e.g., Kubemetes cluster or any platform which supports a running instance of an application) may be in communication with application-specific data repository 504. In an exemplary embodiment, the cluster 502 publishes a public key endpoint URL to application-specific data repository 504. The cluster 502 may include a cluster Certificate Authority (CA) 704 that is configured to issue a plurality of certificates, including, but not limited to, a controller-manager certificate 706, an API-server certificate 708, and a service-account certificate 710. There may be relevant API Server Parameters. For example, relevant API Server Parameters may include, but are not limited to, a service account key file, a service account signing key file, a service account issuer, and a service account API audience. The service account key file may relate to a private key used to sign a service account application identity token. The service account signing key file may relate to a public key used to sign a service account application identity token. The service account issuer may relate to an issuer attribute in the certificate used to sign the application identity token. The service account API audience may relate to at least one service account token that may be transmitted via a projected volume method. The at least one service account token may have a tag with a specified audience value). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by Nainar to include the establishing token is a certification token. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to facilitate an identification of an application that runs on a platform by establishing the identity of the applications that run on the platform and making the identity available, for example, to application containers, nodes, workers, minions, or machines where workloads are deployed such that the applications can seamlessly connect to other services without the need for authentication such as passwords as suggested by HASHMI ([0005]).
As per claim 11: Nainar discloses a master node of a node cluster also ([0016] In configurations, an attestation token may allow for providing a unidirectional integrity check within a cluster of nodes, or between nodes of different clusters) comprising at least one compute node comprising
at least one container intended to execute at least one task ([0006] FIGS. 1A, 1B, and 1C a portion of a container-orchestration system configured in accordance with the Kubernetes platform), said master node ([0024] a portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform. The portion 102 includes a master node 104 and two worker nodes 106a, 106b. As is known, the portion 102 may include many more worker nodes 106. The master node 104 includes an API-server 108 a. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108)comprising
at least one processor configured to:
establish a first instantiation certificate of said master node by means of a first set of certification parameters requested from a certification server ([0026]The request may include a second locally generated nonce generated by the NSM 110a. The NSE pod 114 may generate the second attestation token using the second nonce and provide the second attestation token to the NSM 110a. The NSM 110a may have the attestation token verified by the CA server 120, thereby confirming the integrity of the NSE pod 114. Since the attestation tokens verify the integrity of the pods 112, 114, the NSM 110a may instantiate the integrity verified path 116 between the pod 112 and the NSE pod 114 and inject the integrity verified path 116 into the pod 112);
obtain at least one second instantiation certificate for said container of said compute node ([0019] various protocols are extended to request and send attestation tokens (such as address resolution protocol (ARP), bi-directional forwarding (BFD), control protocols, etc.). The techniques described herein leverage these protocols and let the network service mesh (NSM) query different entities that are involved at the control plane and data plane layer for the integrity verified path instantiation. The local NSM receiving the request for an integrity verified path from the requesting pod may request the attestation token from the NSE pod. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod. When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server. Once the validation is a success, the NSM may instantiate the integrity verified path between the requesting pod and the NSE pod and inject the integrity verified path into the requesting pod),
said second certificate being established by said compute node by means of at least one second set of certification parameters requested from the certification server ([0026]The request may include a second locally generated nonce generated by the NSM 110a. The NSE pod 114 may generate the second attestation token using the second nonce and provide the second attestation token to the NSM 110a. The NSM 110a may have the attestation token verified by the CA server 120, thereby confirming the integrity of the NSE pod 114. Since the attestation tokens verify the integrity of the pods 112, 114, the NSM 110a may instantiate the integrity verified path 116 between the pod 112 and the NSE pod 114 and inject the integrity verified path 116 into the pod 112);
transmit, to said certification server, a request for generating a token of an instantiation of the node cluster ([0013] When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server), said request comprising
said first certificate and said at least one second certificate (The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114) ; and
receive said token of an instantiation of the node cluster generated by the certification server ([0013] generating, by the first pod, the first attestation token, receiving, by the first NSM from the first pod, the first attestation token, and verifying, by the first NSM, the first attestation token with a certificate authority (CA) server. The method may additionally include providing, by the first NSM to the first NSE pod, a third request for a second attestation token, the third request including a second randomly generated nonce and receiving, by the first NSM from the first NSE pod, the second attestation token, the second attestation token being based at least in part on the second randomly generated nonce. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod).
Nainar does not explicitly disclose the establishing token is a certification token. HASHMI, in analogous art however, discloses the establishing token is a certification token ([0098] At Step 3, the sidecar 514 may be implemented to use the application identity token 522 to broker an identity token with enterprise scope 524. In an exemplary embodiment, the pod 510 is provided with a platform internal token 516. In an exemplary embodiment, the platform internal token 516 is a JWT. In another exemplary embodiment, the platform internal identity token 516 is in the form of at least one X.509 certificate. The platform internal token 516 is a signed token which identifies the bearer to a party which trusts the issuer. The platform internal token 516 may be directly or indirectly connected to an API Server 518. A keys API 520 may be provided with the platform internal token 516. The keys API 520 may include or be related to a chain of trust. [0099] In Step 4A, application tokens database 506 may receive or accept an application identity token 522 from Identity Helper Sidecar 514. In an exemplary embodiment, the application identity token 522 is a JWT. In Step 4B, application tokens database 506 may communicate information to Keys API 520. Application tokens database may have a cache which may include a Keys API URL for every cluster. The Keys API URL may be Secure Socket Layer (SSL) enabled with a certificate in the chain of trust. In Step 4C, application tokens database 506 may transmit an identity token with enterprise scope 524 to the Identity Helper Sidecar 514. A micro-service may be created to expose the public key that was used to sign the application identity token 522. Application tokens database 506 may have a certificate in a chain of trust. An SSL connection may be used in Steps 4A through 4C. The SSL connection that may be used in Steps 4A through 4C may use a certificate in the chain of trust. In Step 5, information may be determined by the Identity Helper Sidecar 514. The information determined by the Identity Helper Sidecar 514 may be used by Pod 510. [0100] Referring to FIG. 6, a second data flow diagram 600 is shown. According to an exemplary embodiment, Steps in validating an application identity token 522 are presented. A cluster 502 may include a certificate service 608, an application identity token 522, and an identity token with enterprise scope 524. The cluster 502 may be a Kubernetes cluster or any platform which supports a running instance of an application. The cluster 502 may be configured to communicate with application tokens database 506. Application tokens database 506 may be configured to communicate with application-specific data repository 504. The cluster 502 may create an entry in application-specific data repository 504 for the application identification and cluster combination. Application tokens database 506 may verify the application component and cluster combination before returning the identity token with enterprise scope 524).
HASHMI further discloses ([0104-0105] Referring to FIG. 7, a third data flow diagram 700 is shown. According to an exemplary embodiment, a cluster 502 (e.g., Kubemetes cluster or any platform which supports a running instance of an application) may be in communication with application-specific data repository 504. In an exemplary embodiment, the cluster 502 publishes a public key endpoint URL to application-specific data repository 504. The cluster 502 may include a cluster Certificate Authority (CA) 704 that is configured to issue a plurality of certificates, including, but not limited to, a controller-manager certificate 706, an API-server certificate 708, and a service-account certificate 710. There may be relevant API Server Parameters. For example, relevant API Server Parameters may include, but are not limited to, a service account key file, a service account signing key file, a service account issuer, and a service account API audience. The service account key file may relate to a private key used to sign a service account application identity token. The service account signing key file may relate to a public key used to sign a service account application identity token. The service account issuer may relate to an issuer attribute in the certificate used to sign the application identity token. The service account API audience may relate to at least one service account token that may be transmitted via a projected volume method. The at least one service account token may have a tag with a specified audience value). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by Nainar to include the establishing token is a certification token. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to facilitate an identification of an application that runs on a platform by establishing the identity of the applications that run on the platform and making the identity available, for example, to application containers, nodes, workers, minions, or machines where workloads are deployed such that the applications can seamlessly connect to other services without the need for authentication such as passwords as suggested by HASHMI ([0005]).
As per claim 12: Nainar discloses a certification server capable of establishing a token of an instantiation of a node cluster comprising ([0016] In configurations, an attestation token may allow for providing a unidirectional integrity check within a cluster of nodes, or between nodes of different clusters)
a master node and at least one compute node ([0024] a portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform. The portion 102 includes a master node 104 and two worker nodes 106a, 106b. As is known, the portion 102 may include many more worker nodes 106. The master node 104 includes an API-server 108 a. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108) comprising
at least one container intended to execute at least one task ([0006] FIGS. 1A, 1B, and 1C a portion of a container-orchestration system configured in accordance with the Kubernetes platform), said certification server comprising
at least one processor configured to: transmit a first set of certification parameters to said master node ([0013] When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server);
transmit at least one second set of certification parameters to at least one container of said compute node ([0021] The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token);
receive, from said master node, a request for generating said token of an instantiation of the node cluster ([0019] The local NSM receiving the request for an integrity verified path from the requesting pod may request the attestation token from the NSE pod. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod. When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server),
said request comprising
a first instantiation certificate of said master node established by means of the first set of certification parameters ([0024] The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114) and
at least one second instantiation certificate of said container established by means of the second set of certification parameters ([0026]The request may include a second locally generated nonce generated by the NSM 110a. The NSE pod 114 may generate the second attestation token using the second nonce and provide the second attestation token to the NSM 110a. The NSM 110a may have the attestation token verified by the CA server 120, thereby confirming the integrity of the NSE pod 114. Since the attestation tokens verify the integrity of the pods 112, 114, the NSM 110a may instantiate the integrity verified path 116 between the pod 112 and the NSE pod 114 and inject the integrity verified path 116 into the pod 112);
generate said token of an instantiation of the node cluster by means of said first certificate and said at least one second certificate ([0013] generating, by the first pod, the first attestation token, receiving, by the first NSM from the first pod, the first attestation token, and verifying, by the first NSM, the first attestation token with a certificate authority (CA) server. The method may additionally include providing, by the first NSM to the first NSE pod, a third request for a second attestation token, the third request including a second randomly generated nonce and receiving, by the first NSM from the first NSE pod, the second attestation token, the second attestation token being based at least in part on the second randomly generated nonce. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod); and
transmit said token of an instantiation of the node cluster to said master node ([0013] When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server).
Nainar does not explicitly disclose the establishing token is a certification token. HASHMI, in analogous art however, discloses the establishing token is a certification token ([0098] At Step 3, the sidecar 514 may be implemented to use the application identity token 522 to broker an identity token with enterprise scope 524. In an exemplary embodiment, the pod 510 is provided with a platform internal token 516. In an exemplary embodiment, the platform internal token 516 is a JWT. In another exemplary embodiment, the platform internal identity token 516 is in the form of at least one X.509 certificate. The platform internal token 516 is a signed token which identifies the bearer to a party which trusts the issuer. The platform internal token 516 may be directly or indirectly connected to an API Server 518. A keys API 520 may be provided with the platform internal token 516. The keys API 520 may include or be related to a chain of trust. [0099] In Step 4A, application tokens database 506 may receive or accept an application identity token 522 from Identity Helper Sidecar 514. In an exemplary embodiment, the application identity token 522 is a JWT. In Step 4B, application tokens database 506 may communicate information to Keys API 520. Application tokens database may have a cache which may include a Keys API URL for every cluster. The Keys API URL may be Secure Socket Layer (SSL) enabled with a certificate in the chain of trust. In Step 4C, application tokens database 506 may transmit an identity token with enterprise scope 524 to the Identity Helper Sidecar 514. A micro-service may be created to expose the public key that was used to sign the application identity token 522. Application tokens database 506 may have a certificate in a chain of trust. An SSL connection may be used in Steps 4A through 4C. The SSL connection that may be used in Steps 4A through 4C may use a certificate in the chain of trust. In Step 5, information may be determined by the Identity Helper Sidecar 514. The information determined by the Identity Helper Sidecar 514 may be used by Pod 510. [0100] Referring to FIG. 6, a second data flow diagram 600 is shown. According to an exemplary embodiment, Steps in validating an application identity token 522 are presented. A cluster 502 may include a certificate service 608, an application identity token 522, and an identity token with enterprise scope 524. The cluster 502 may be a Kubernetes cluster or any platform which supports a running instance of an application. The cluster 502 may be configured to communicate with application tokens database 506. Application tokens database 506 may be configured to communicate with application-specific data repository 504. The cluster 502 may create an entry in application-specific data repository 504 for the application identification and cluster combination. Application tokens database 506 may verify the application component and cluster combination before returning the identity token with enterprise scope 524.
HASHMI further discloses ([0104-0105] Referring to FIG. 7, a third data flow diagram 700 is shown. According to an exemplary embodiment, a cluster 502 (e.g., Kubemetes cluster or any platform which supports a running instance of an application) may be in communication with application-specific data repository 504. In an exemplary embodiment, the cluster 502 publishes a public key endpoint URL to application-specific data repository 504. The cluster 502 may include a cluster Certificate Authority (CA) 704 that is configured to issue a plurality of certificates, including, but not limited to, a controller-manager certificate 706, an API-server certificate 708, and a service-account certificate 710. There may be relevant API Server Parameters. For example, relevant API Server Parameters may include, but are not limited to, a service account key file, a service account signing key file, a service account issuer, and a service account API audience. The service account key file may relate to a private key used to sign a service account application identity token. The service account signing key file may relate to a public key used to sign a service account application identity token. The service account issuer may relate to an issuer attribute in the certificate used to sign the application identity token. The service account API audience may relate to at least one service account token that may be transmitted via a projected volume method. The at least one service account token may have a tag with a specified audience value). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by Nainar to include the establishing token is a certification token. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to facilitate an identification of an application that runs on a platform by establishing the identity of the applications that run on the platform and making the identity available, for example, to application containers, nodes, workers, minions, or machines where workloads are deployed such that the applications can seamlessly connect to other services without the need for authentication such as passwords as suggested by HASHMI ([0005]).
As per claim 14: Nainar discloses an item of equipment to access a service implemented by a node cluster comprising ([0016] In configurations, an attestation token may allow for providing a unidirectional integrity check within a cluster of nodes, or between nodes of different clusters) a master node and at least one compute node([0024] a portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform. The portion 102 includes a master node 104 and two worker nodes 106a, 106b. As is known, the portion 102 may include many more worker nodes 106. The master node 104 includes an API-server 108 a. The worker nodes 106a, 106b include network service meshes (NSMs) 110a, 110b, respectively, that communicate with the API-server 108) comprising
at least one container intended to execute at least one task ([0006] FIGS. 1A, 1B, and 1C a portion of a container-orchestration system configured in accordance with the Kubernetes platform), said item of equipment comprising
at least one processor configured to: transmit, to said master node, a request for establishing a session with said node cluster ([0019] The local NSM receiving the request for an integrity verified path from the requesting pod may request the attestation token from the NSE pod. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod. When the identified NSE pod is external, e.g., in a remote cluster or cloud maintained by a different NSM, the attestation token request is sent to both the remote NSM and the NSE pod to obtain an attestation token from both the remote NSM and the NSE pod. Upon receiving the attestation token(s), the local NSM performs a validation of the attestation token(s) with a certificate authority (CA) server);
receive a signalling message relating to the establishment of said session ([0025] The request for the integrity verified path 116 that is sent to the NSM 110a may include various attributes. For example, the request may include attributes such as, for example, a label (e.g., conditions for selecting a NSE for providing a desired service), a network service (e.g., the type of desired service), and a color (e.g., quality of service). In configurations, the request may also include integrity attributes including integrity-verified (an indication if the node that includes the NSE pod should be integrity verified) and continuous (an indication if the node that includes the NSE pod needs to only initially be integrity verified or if the node should be periodically re-validated for integrity, e.g., the node should be continuously integrity verified) further comprising
said token established by a certification server by means of a first instantiation certificate of said master node established by means of a first set of certification parameters requested from the certification server ([0024] The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114The local NSM 110a receiving the request for the integrity verified path 116 from the requesting pod 112 may request an attestation token from the pod 112. The portion 102 of a container-orchestration system configured in accordance with the Kubernetes platform, when the pod 112 and the NSE pod 114 are part of the same cluster or cloud, e.g., the worker node 106a and the worker node 106b are part of the same cluster or cloud and thus, both include NSM 110a, the NSM 110a may locally generate a nonce and provide the nonce to the pod 112, where the request includes a request for an attestation token. Using the nonce, the pod 112 may generate the attestation token and reply back to the NSM 110a. The NSM 110a may then have the attestation token verified by a certificate authority (CA) server 120, thereby confirming the integrity of the pod 112. The NSM 110a may generate a second request for an attestation token and forward it to the NSE pod 114); and
at least one second instantiation certificate of said container established by means of a second set of certification parameters requested from the certification server ([0026]The request may include a second locally generated nonce generated by the NSM 110a. The NSE pod 114 may generate the second attestation token using the second nonce and provide the second attestation token to the NSM 110a. The NSM 110a may have the attestation token verified by the CA server 120, thereby confirming the integrity of the NSE pod 114. Since the attestation tokens verify the integrity of the pods 112, 114, the NSM 110a may instantiate the integrity verified path 116 between the pod 112 and the NSE pod 114 and inject the integrity verified path 116 into the pod 112); and
verify the authenticity of said token with said certification server ([0013] generating, by the first pod, the first attestation token, receiving, by the first NSM from the first pod, the first attestation token, and verifying, by the first NSM, the first attestation token with a certificate authority (CA) server. The method may additionally include providing, by the first NSM to the first NSE pod, a third request for a second attestation token, the third request including a second randomly generated nonce and receiving, by the first NSM from the first NSE pod, the second attestation token, the second attestation token being based at least in part on the second randomly generated nonce. When the identified remote NSE pod is within the same cluster or cloud where the NSM is responsible (e.g., the local NSM), the attestation token request is sent directly to the NSE pod).
Nainar does not explicitly disclose the establishing token is a certification token. HASHMI, in analogous art however, discloses the establishing token is a certification token ([0098] At Step 3, the sidecar 514 may be implemented to use the application identity token 522 to broker an identity token with enterprise scope 524. In an exemplary embodiment, the pod 510 is provided with a platform internal token 516. In an exemplary embodiment, the platform internal token 516 is a JWT. In another exemplary embodiment, the platform internal identity token 516 is in the form of at least one X.509 certificate. The platform internal token 516 is a signed token which identifies the bearer to a party which trusts the issuer. The platform internal token 516 may be directly or indirectly connected to an API Server 518. A keys API 520 may be provided with the platform internal token 516. The keys API 520 may include or be related to a chain of trust. [0099] In Step 4A, application tokens database 506 may receive or accept an application identity token 522 from Identity Helper Sidecar 514. In an exemplary embodiment, the application identity token 522 is a JWT. In Step 4B, application tokens database 506 may communicate information to Keys API 520. Application tokens database may have a cache which may include a Keys API URL for every cluster. The Keys API URL may be Secure Socket Layer (SSL) enabled with a certificate in the chain of trust. In Step 4C, application tokens database 506 may transmit an identity token with enterprise scope 524 to the Identity Helper Sidecar 514. A micro-service may be created to expose the public key that was used to sign the application identity token 522. Application tokens database 506 may have a certificate in a chain of trust. An SSL connection may be used in Steps 4A through 4C. The SSL connection that may be used in Steps 4A through 4C may use a certificate in the chain of trust. In Step 5, information may be determined by the Identity Helper Sidecar 514. The information determined by the Identity Helper Sidecar 514 may be used by Pod 510. [0100] Referring to FIG. 6, a second data flow diagram 600 is shown. According to an exemplary embodiment, Steps in validating an application identity token 522 are presented. A cluster 502 may include a certificate service 608, an application identity token 522, and an identity token with enterprise scope 524. The cluster 502 may be a Kubernetes cluster or any platform which supports a running instance of an application. The cluster 502 may be configured to communicate with application tokens database 506. Application tokens database 506 may be configured to communicate with application-specific data repository 504. The cluster 502 may create an entry in application-specific data repository 504 for the application identification and cluster combination. Application tokens database 506 may verify the application component and cluster combination before returning the identity token with enterprise scope 524).
HASHMI further discloses ([0104-0105] Referring to FIG. 7, a third data flow diagram 700 is shown. According to an exemplary embodiment, a cluster 502 (e.g., Kubemetes cluster or any platform which supports a running instance of an application) may be in communication with application-specific data repository 504. In an exemplary embodiment, the cluster 502 publishes a public key endpoint URL to application-specific data repository 504. The cluster 502 may include a cluster Certificate Authority (CA) 704 that is configured to issue a plurality of certificates, including, but not limited to, a controller-manager certificate 706, an API-server certificate 708, and a service-account certificate 710. There may be relevant API Server Parameters. For example, relevant API Server Parameters may include, but are not limited to, a service account key file, a service account signing key file, a service account issuer, and a service account API audience. The service account key file may relate to a private key used to sign a service account application identity token. The service account signing key file may relate to a public key used to sign a service account application identity token. The service account issuer may relate to an issuer attribute in the certificate used to sign the application identity token. The service account API audience may relate to at least one service account token that may be transmitted via a projected volume method. The at least one service account token may have a tag with a specified audience value). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations disclosed by Nainar to include the establishing token is a certification token. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to facilitate an identification of an application that runs on a platform by establishing the identity of the applications that run on the platform and making the identity available, for example, to application containers, nodes, workers, minions, or machines where workloads are deployed such that the applications can seamlessly connect to other services without the need for authentication such as passwords as suggested by HASHMI ([0005]).
BRI (Broadest Reasonable Interpretation) Considerations
The above claims under examination have been given to them their BRI considerations consistent with the applicant’s disclosure as they would be interpreted by ordinary skill in the art (POSITA) at the time of filing of the invention. In order to construe, appraise boundary and scope of the claimed limitations, the following claim words or terms or phrases or languages have been given to them their BRI considerations and context in view of the applicant’s disclosure. For record clarity, BRI for the following claim words or terms or phrases or languages, the examiner recites descriptions from the applicant’s disclosure as follows:
Node Cluster, Master node, compute node and Containers: [Applicant’s Disclosure: 0007-0009] FIG. 1 shows in a simplified manner the architecture of a node cluster 1 compliant with the Kubernetes architecture. The node cluster 1 comprises a first node 10 referred to as master node, or “Kubernetes master”, and N compute nodes, or “workers nodes”, 11i, i∈{1, . . . , N}, N being a natural integer. The master node 10 comprises a controller 101, an API (Application Programming Interface) module 102 and an ETCD database 103 that consists of a dynamic configuration register for the compute nodes 11i. A compute node 11i comprises M containers or “pods” 110j, j∈{1, . . . , M}, M being a natural integer. Each container 110j is equipped with resources for executing one or more tasks. When a task is executed, it contributes to implementing a network service or a function, such as a DHCP (Dynamic Host Configuration Protocol) function, for example.
[0119-0120] Such a system comprises at least one node cluster 1 compliant with the Kubernetes architecture. The node cluster 1 comprises a first node 10 referred to as master node and N compute nodes 11i, i∈{1, . . . , N}, N being a natural integer. A compute node 11i comprises M containers or “pods” 110j, j∈{1, . . . , M}, M being a natural integer. Each container 110j is equipped with resources for executing one or more tasks. When a task is executed, it contributes to implementing a network service or a function, such as a DHCP (Dynamic Host Configuration Protocol) function, for example.
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure. See the notice of reference cited in form PTO-892 for additional prior arts.
THIS ACTION IS MADE FINAL. 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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
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, LINGLAN EDWARDS can be reached at (571) 270-5440. 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.
/TECHANE GERGISO/Primary Examiner, Art Unit 2408
Prosecution Insights