Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) are rejected under 103, have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant argued in the remark that Applicant respectfully submits that claims 1, 9 and 15 are patentable over the combination of cited references because the combination does not teach or suggest all the features of the claims. Notwithstanding the foregoing, and in the interest of compact prosecution, Applicant has amended independent claims 1, 9, and 15, to clarify that the validating, generating, and providing operations are performed by the first cluster.
Examiner respectfully disagrees. Hockey discloses A method comprising:
receiving, by a first cluster of secure environments comprising one or more processing devices, a request to provide a data object attestation authority certificate to a second cluster of secure environments ( fig.2, 0033 Certificate chains are formed from the root certificate whereby the first cluster has a first cluster certificate 202 and the second cluster has a second cluster certificate 204, wherein the cluster1 206 received a request of the cluster 1 certificate 202, i.e. attestation authority certificate from the Root certificate 200 for authenticate the cluster 2 0084 0087] a client in the first cluster, the client originating traffic to a second cluster for processing, the second cluster having access to the root certificate; [0089] route the traffic to the second cluster using a secure communications protocol with mutual authentication; ) the request comprising a cluster certificate of the second cluster issued by a cluster enrollment certificate authority(CA) (0033 The control plane 208 of the first cluster 206 uses the first cluster certificate to issue leaf certificates to its proxies 212 such that the leaf certificates are also ultimately signed by the root certificate 200, i.e. CA, that sends the request that includes the cluster1 certificate 202. And 0046 The service mesh at the first cluster is used to ensure 300 traffic within the first cluster is communicated within the first cluster using a secure communications protocol with mutual authentication accomplished using a root certificate. );
validating, by the first cluster, the cluster certificate of the second cluster using a public key of the cluster enrollment CA (0036 The proxy in the first cluster validates the certificate chain of the proxy in the second cluster. The proxy in the second cluster validates the certificate chain of the proxy in the first cluster. And 0047 A client in a unit in the first cluster decides to send 302 traffic to a server in the second cluster and so sends traffic to an address of a port at the server in the second cluster. [0048] The first cluster carries out 306 mutual authentication with the second cluster. More specifically, a client in a unit of the first cluster which is configured to forward the traffic to a server in a unit in the second cluster establishes a communication session with the server. As part of the establishment of the communication session, mutual authentication is carried out using a handshake process such as a TLS handshake.);
generating, by the first cluster, an encrypted message comprising the data object attestation authority certificate (0057 The service mesh of the first cluster will use this signing certificate to issue leaf certificates, i.e. an encrypted message, / data object attestation authority certificate, to its proxies, 212 meaning these leaves will also be signed by the root ) and a digital signature of the first cluster, wherein the encrypted message is encrypted using a public key indicated in the cluster certificate of the second cluster ( 0055 A service mesh might only accept client certificates that have been signed by the local cluster (and include the local cluster’s “trust domain” string, i. e. by the first cluster, )), and
wherein the digital signature of the first cluster is associated with a cluster certificate of the first cluster issued by the cluster enrollment CA ( 0057 The service mesh of the first cluster will use this signing certificate to issue leaf certificates, i.e. an encrypted message, / data object attestation authority certificate, to its proxies, 212 meaning these leaves will also be signed by the root and 0058The service mesh might only accept server certificates that have been signed by the local cluster (and include the local cluster’s “trust domain” string). In this case it is possible to relax this checking to either allow certain well know cluster names, or allow any name that matches an expression, or allow any certificate that is signed by the root. ); and
providing, by the first cluster, to the second cluster, the encrypted message to be decrypted using a private key of the second cluster associated with the cluster certificate of the second cluster, and to be validated using at least the public key of the cluster enrollment CA(0067 [0069] using a client in the first cluster, originating traffic to a second cluster for processing, the second cluster having access to the root certificate; [0070] using the first service mesh, routing the traffic to the second cluster using a secure communications protocol with mutual authentication; [0071] carrying out mutual authentication between the first cluster and the second cluster using certificate chains having the root certificate; and [0072] in response to the mutual authentication being successful, routing application data from the client to the second cluster using the secure communications protocol such that the application data, i.e. encrypted message , i.e. the issue leaf certificates, i.e. an encrypted message, / data object attestation authority certificate may be processed at the second cluster to provide the service).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Hockey et al US 2023/0353392 in view of Tarkhanyan et al US 2022/0094690.
As per claim 1, Hockey discloses A method comprising:
receiving, by a first cluster of secure environments comprising one or more processing devices, a request to provide a data object attestation authority certificate to a second cluster of secure environments ( fig.2, 0033 Certificate chains are formed from the root certificate whereby the first cluster has a first cluster certificate 202 and the second cluster has a second cluster certificate 204, wherein the cluster1 206 received a request of the cluster 1 certificate 202, i.e. attestation authority certificate from the Root certificate 200 for authenticate the cluster 2 0084 0087] a client in the first cluster, the client originating traffic to a second cluster for processing, the second cluster having access to the root certificate; [0089] route the traffic to the second cluster using a secure communications protocol with mutual authentication; ) the request comprising a cluster certificate of the second cluster issued by a cluster enrollment certificate authority(CA) (0033 The control plane 208 of the first cluster 206 uses the first cluster certificate to issue leaf certificates to its proxies 212 such that the leaf certificates are also ultimately signed by the root certificate 200, i.e. CA, that sends the request that includes the cluster1 certificate 202. And 0046 The service mesh at the first cluster is used to ensure 300 traffic within the first cluster is communicated within the first cluster using a secure communications protocol with mutual authentication accomplished using a root certificate. );
validating, by the first cluster, the cluster certificate of the second cluster using a public key of the cluster enrollment CA (0036 The proxy in the first cluster validates the certificate chain of the proxy in the second cluster. The proxy in the second cluster validates the certificate chain of the proxy in the first cluster. And 0047 A client in a unit in the first cluster decides to send 302 traffic to a server in the second cluster and so sends traffic to an address of a port at the server in the second cluster. [0048] The first cluster carries out 306 mutual authentication with the second cluster. More specifically, a client in a unit of the first cluster which is configured to forward the traffic to a server in a unit in the second cluster establishes a communication session with the server. As part of the establishment of the communication session, mutual authentication is carried out using a handshake process such as a TLS handshake.);
generating, by the first cluster, an encrypted message comprising the data object attestation authority certificate (0057 The service mesh of the first cluster will use this signing certificate to issue leaf certificates, i.e. an encrypted message, / data object attestation authority certificate, to its proxies, 212 meaning these leaves will also be signed by the root ) and a digital signature of the first cluster, wherein the encrypted message is encrypted using a public key indicated in the cluster certificate of the second cluster ( 0055 A service mesh might only accept client certificates that have been signed by the local cluster (and include the local cluster’s “trust domain” string, i. e. by the first cluster, )), and
wherein the digital signature of the first cluster is associated with a cluster certificate of the first cluster issued by the cluster enrollment CA ( 0057 The service mesh of the first cluster will use this signing certificate to issue leaf certificates, i.e. an encrypted message, / data object attestation authority certificate, to its proxies, 212 meaning these leaves will also be signed by the root and 0058The service mesh might only accept server certificates that have been signed by the local cluster (and include the local cluster’s “trust domain” string). In this case it is possible to relax this checking to either allow certain well know cluster names, or allow any name that matches an expression, or allow any certificate that is signed by the root. ); and
providing, by the first cluster, to the second cluster, the encrypted message to be decrypted using a private key of the second cluster associated with the cluster certificate of the second cluster, and to be validated using at least the public key of the cluster enrollment CA(0067 [0069] using a client in the first cluster, originating traffic to a second cluster for processing, the second cluster having access to the root certificate; [0070] using the first service mesh, routing the traffic to the second cluster using a secure communications protocol with mutual authentication; [0071] carrying out mutual authentication between the first cluster and the second cluster using certificate chains having the root certificate; and [0072] in response to the mutual authentication being successful, routing application data from the client to the second cluster using the secure communications protocol such that the application data, i.e. encrypted message , i.e. the issue leaf certificates, i.e. an encrypted message, / data object attestation authority certificate may be processed at the second cluster to provide the service. ).
But Hockey does not disclose attestation data to the clusters,
However, Tarkhanyan discloses attestation data to the clusters,
(at 606. And fig. 6B provide attestation data of the first security manager to the tenant, and provide an attestation report to the tenant, the attestation report indicating whether attestations were successful for one or more compute nodes in the first node cluster and one or more compute nodes in the second node cluster.),
Hockey and Tarkhanyan are both considered to be analogous to the claimed invention because they are in the same field of cluster network.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hockeyto incorporate the teachings of Tarkhanyan and provide an attestation repoert.
Doing so would provide the authenticity of the report, thereby increasing report privacy.
As per claim 2. Hockey and Tarkhanyan discloses the method of claim 1,Hockey discloses further comprising: prior to generating the encrypted message, enrolling the first cluster in a distributed data object attestation system, wherein enrolling the first cluster further comprises: generating a request for the cluster certificate of the first cluster, wherein the request comprises a public key of the first cluster and one or more secure environment certificates each associated with a manufacturer of a respective secure environment of the first cluster (fig.2, [0067] Clause A. A method of processing traffic in a communications network in order to provide a service, the method comprising: [0068] using a first service mesh in the first cluster to ensure the received traffic is communicated within the first cluster using a secure communications protocol with mutual authentication accomplished using a certificate chain having a root certificate; [0069] using a client in the first cluster, originating traffic to a second cluster for processing, the second cluster having access to the root certificate; [0070] using the first service mesh, routing the traffic to the second cluster using a secure communications protocol with mutual authentication; [0071] carrying out mutual authentication between the first cluster and the second cluster using certificate chains having the root certificate; and [0072] in response to the mutual authentication being successful, routing application data from the client to the second cluster using the secure communications protocol such that the application data may be processed at the second cluster to provide the service. ); providing the request to the cluster enrollment CA to be validated using one or more manufacturer public keys each associated with a respective secure environment certificate of the one or more secure environment certificates ( [0006] A method of processing traffic to provide a service is described. A first service mesh in a first cluster is used to ensure traffic is communicated within the first cluster using a secure communications protocol with mutual authentication accomplished using a certificate chain having a root certificate. A client in the first cluster originates traffic to a second cluster for processing, the second cluster having access to the root certificate. Using the first service mesh, routing the traffic to the second cluster is done using a secure communications protocol with mutual authentication. Mutual authentication is carried out between the first cluster and the second cluster using certificate chains having the root certificate; and in response to the mutual authentication being successful, application data is routed to the second cluster using the secure communications protocol such that the application data may be processed at the second cluster to provide the service.); and receiving the cluster certificate of the first cluster from the cluster enrollment CA ( [0006] A method of processing traffic to provide a service is described. A first service mesh in a first cluster is used to ensure traffic is communicated within the first cluster using a secure communications protocol with mutual authentication accomplished using a certificate chain having a root certificate. A client in the first cluster originates traffic to a second cluster for processing, the second cluster having access to the root certificate. Using the first service mesh, routing the traffic to the second cluster is done using a secure communications protocol with mutual authentication. Mutual authentication is carried out between the first cluster and the second cluster using certificate chains having the root certificate; and in response to the mutual authentication being successful, application data is routed to the second cluster using the secure communications protocol such that the application data may be processed at the second cluster to provide the service.).
As per claim 3. Hockey and Tarkhanyan discloses The method of claim 1,Hockey discloses further comprising: prior to generating the encrypted message, obtaining the data object attestation authority certificate from a distributed attestation CA, wherein obtaining the data object attestation authority certificate further comprises: generating a request for the data object attestation authority certificate, the request comprising the cluster certificate of the first cluster ( fig.2, two clusters of the communications network of FIG. 1. FIG. 2 shows a first cluster 206 and a second cluster 218. The first cluster 206 has a control plane 208 and a plurality of units 214 together forming a first service mesh. Each of the units 214 has a proxy and a client or server. At least one of the units 214 comprises a client 210 and a proxy 212. The second cluster 218 also has a control plane 216 and a plurality of units 224 together forming a second service mesh. Each of the units 224 has a proxy 220 and a client or server 222. The first and second service meshes are independent of one another since they do not share information except for a root certificate 200 ); providing the request to the distributed attestation CA to be validated using the public key of the cluster enrollment CA; and receiving the data object attestation authority certificate from the distributed attestation CA (fig.2, two clusters of the communications network of FIG. 1. FIG. 2 shows a first cluster 206 and a second cluster 218. The first cluster 206 has a control plane 208 and a plurality of units 214 together forming a first service mesh. Each of the units 214 has a proxy and a client or server. At least one of the units 214 comprises a client 210 and a proxy 212. The second cluster 218 also has a control plane 216 and a plurality of units 224 together forming a second service mesh. Each of the units 224 has a proxy 220 and a client or server 222. The first and second service meshes are independent of one another since they do not share information except for a root certificate 200).
As per claim 4. Hockey and Tarkhanyan discloses The method of claim 3, Hockey discloses wherein: the cluster enrollment CA is associated with a cluster enrollment CA certificate issued by a common root CA; and the distributed attestation CA is associated with a distributed attestation CA certificate issued by the common root CA ( par 0031 fig.2, two clusters of the communications network of FIG. 1. FIG. 2 shows a first cluster 206 and a second cluster 218. The first cluster 206 has a control plane 208 and a plurality of units 214 together forming a first service mesh. Each of the units 214 has a proxy and a client or server. At least one of the units 214 comprises a client 210 and a proxy 212. The second cluster 218 also has a control plane 216 and a plurality of units 224 together forming a second service mesh. Each of the units 224 has a proxy 220 and a client or server 222. The first and second service meshes are independent of one another since they do not share information except for a root certificate 200).
As per claim 5. Hockey and Tarkhanyan discloses The method of claim 1, Hockey discloses further comprising: receiving a request of an entity to provide an attestation for a data object, the request comprising an identifier of the data object; identifying a storage location of the data object to be the first cluster; identifying one or more attributes of the data object ([0033] A root certificate 200 is available at a secure location in the communications network 100 of FIG. 1 and is accessible to both the clusters. Certificate chains are formed from the root certificate whereby the first cluster has a first cluster certificate 202 and the second cluster has a second cluster certificate 204. The control plane 208 of the first cluster 206 uses the first cluster certificate to issue leaf certificates to its proxies 212 such that the leaf certificates are also ultimately signed by the root certificate 200. The control plane 216 of the second cluster 218 uses the second cluster certificate 204 to issue leaf certificates to its proxies 220 such that the leaf certificates are also ultimately signed by the root certificate. Thus each service mesh trusts the root certificate 200. The control plane 208 in the first cluster and control plane 216 in the second cluster ensure that secure communication protocol handshakes are signed by the common root certificate 200. Thus units 214, 224 are able to verify each other’s certificates because they trust the root certificate 200. The present example uses three levels of certificate: root, intermediate and leaf. However, it is also possible to have more than three levels of certificate by adding more intermediate levels. ); generating the attestation, wherein the attestation comprises the identifier of the data object, the one or more attributes of the data object, and a digital signature associated with the data object attestation authority certificate; and providing the attestation to the entity([0034] Suppose that the clusters of FIG. 2 are used to process traffic in order to provide a secure service. A client at unit 214 of the first cluster decides to initiate a connection to a server that is not in the same cluster. A first service mesh in the first cluster 206 is being used to ensure that traffic is communicated within the first cluster using a secure communications protocol with mutual authentication accomplished using a certificate chain having a root certificate 200. When the client at unit 214 of the first cluster initiates a connection to a server that is not in the same cluster, the client sends traffic addressed to a port at the server in the second cluster. The traffic travels via the proxy in the unit 214 due to the service mesh in the first cluster. The proxy is part of the first service mesh and so it secures traffic destined within the first cluster. However, the request is addressed to an address outside the first cluster so normally the proxy would forward the traffic in an unsecured manner. However, a configuration of the proxy has been arranged to ensure the traffic is sent using a secure protocol with mutual authentication. The configuration is static and agnostic to the topology of the destination cluster. The second cluster 201 has access to the root certificate 200. Mutual authentication is carried out between the first cluster 206 and the second cluster 218 using certificate chains having the root certificate 200. If the mutual authentication is successful the client in the first cluster proceeds to send application data to the server in the second cluster over the secure, mutually authenticated route. The control plane is optionally modified so that the first cluster does not access any other services using the specified port. In this way, inadvertent transmission of other services outside the cluster is avoided).
As per claim 6. Hockey and Tarkhanyan discloses The method of claim 5, Hockey discloses wherein the data object comprises one or more of: a permissible usage attribute indicating for what purposes the data object may be used, an origination attribute indicating whether the data object was generated in a secure environment of the first cluster, or an export attribute indicating whether the data object may be exported from the first cluster ([0034] Suppose that the clusters of FIG. 2 are used to process traffic in order to provide a secure service. A client at unit 214 of the first cluster decides to initiate a connection to a server that is not in the same cluster. A first service mesh in the first cluster 206 is being used to ensure that traffic is communicated within the first cluster using a secure communications protocol with mutual authentication accomplished using a certificate chain having a root certificate 200. When the client at unit 214 of the first cluster initiates a connection to a server that is not in the same cluster, the client sends traffic addressed to a port at the server in the second cluster. The traffic travels via the proxy in the unit 214 due to the service mesh in the first cluster. The proxy is part of the first service mesh and so it secures traffic destined within the first cluster. However, the request is addressed to an address outside the first cluster so normally the proxy would forward the traffic in an unsecured manner. However, a configuration of the proxy has been arranged to ensure the traffic is sent using a secure protocol with mutual authentication. The configuration is static and agnostic to the topology of the destination cluster. The second cluster 201 has access to the root certificate 200. Mutual authentication is carried out between the first cluster 206 and the second cluster 218 using certificate chains having the root certificate 200. If the mutual authentication is successful the client in the first cluster proceeds to send application data to the server in the second cluster over the secure, mutually authenticated route. The control plane is optionally modified so that the first cluster does not access any other services using the specified port. In this way, inadvertent transmission of other services outside the cluster is avoided).
As per claim 7. Hockey and Tarkhanyan discloses The method of claim 1, Tarkhanyan discloses further comprising: receiving a request of an entity to provide an attestation for a data object, the request comprising an identifier of the data object; identifying a storage location of the data object to be the second cluster; obtaining one or more attributes of the data object from the second cluster (0061] Security manager 152 gathers attestation data 234 from the nodes assigned to the workload by orchestrator 154, which include the compute nodes in node cluster B 158 in this example. Security manager 152 can attempt to attest each compute node in node cluster B 158 based on the compute nodes attestation data and relevant policy requirements specified in the WEP. Alternatively, security manager 152 can attempt to attest the compute nodes as a cluster (or pool) based on the attestation data and relevant policy requirements specified in the WEP. The relevant policy requirements used to attest the assigned resources in the supporting compute domain 150 may be obtained by security manager 152 from the trust manifest or directly from the WEP. Security manager 152 can send attestation results 238 to security manager 112. In at least one embodiment, the relevant policy requirements include security requirements. ); generating the attestation, wherein the attestation comprises the identifier of the data object, the one or more attributes of the data object, and a digital signature associated with the data object attestation authority certificate; and providing the attestation to the entity(his attestation of the pool of resources may be performed instead of individual attestations. In other embodiments, individual attestations may be performed instead of, or in addition to, the attestation of the pool of resources. Thus, in some embodiments the attestation report may also include specific information about current member devices in the node cluster (or pool of resources) attested by the security manager. In addition, in order to bring multiple node clusters (which are each assigned to the same workload) in different compute domains into a secure connected compute fabric spanning the different compute domains, security managers in the different compute domains collaborate to enforce the tenant's workload execution policy for the workload across all node clusters assigned to the workload).
As per claim 8. Hockey and Tarkhanyan discloses The method of claim 1, Hockey discloses wherein the encrypted message is to be further validated using at least the cluster certificate of the first cluster(0057 The service mesh of the first cluster will use this signing certificate to issue leaf certificates, i.e. an encrypted message, / data object attestation authority certificate, to its proxies, 212 meaning these leaves will also be signed by the root and 0058The service mesh might only accept server certificates that have been signed by the local cluster (and include the local cluster’s “trust domain” string)).
As per claim 9. Hockey discloses a system comprising: a memory device(0064 memory 508, ); and a first cluster of secure environments comprising processing device circuitry coupled to the memory device( 0019/0063 the subscriber device to the specified cluster ), the processing device circuitry to perform operations comprising:
receiving, by a first cluster of secure environments comprising one or more processing devices, a request to provide a data object attestation authority certificate to a second cluster of secure environments ( fig.2, 0033 Certificate chains are formed from the root certificate whereby the first cluster has a first cluster certificate 202 and the second cluster has a second cluster certificate 204, wherein the cluster1 206 received a request of the cluster 1 certificate 202, i.e. attestation authority certificate from the Root certificate 200 for authenticate the cluster 2 0084 0087] a client in the first cluster, the client originating traffic to a second cluster for processing, the second cluster having access to the root certificate; [0089] route the traffic to the second cluster using a secure communications protocol with mutual authentication; ) the request comprising a cluster certificate of the second cluster issued by a cluster enrollment certificate authority(CA) (0033 The control plane 208 of the first cluster 206 uses the first cluster certificate to issue leaf certificates to its proxies 212 such that the leaf certificates are also ultimately signed by the root certificate 200, i.e. CA, that sends the request that includes the cluster1 certificate 202. And 0046 The service mesh at the first cluster is used to ensure 300 traffic within the first cluster is communicated within the first cluster using a secure communications protocol with mutual authentication accomplished using a root certificate. );
validating, by the first cluster, the cluster certificate of the second cluster using a public key of the cluster enrollment CA (0036 The proxy in the first cluster validates the certificate chain of the proxy in the second cluster. The proxy in the second cluster validates the certificate chain of the proxy in the first cluster. And 0047 A client in a unit in the first cluster decides to send 302 traffic to a server in the second cluster and so sends traffic to an address of a port at the server in the second cluster. [0048] The first cluster carries out 306 mutual authentication with the second cluster. More specifically, a client in a unit of the first cluster which is configured to forward the traffic to a server in a unit in the second cluster establishes a communication session with the server. As part of the establishment of the communication session, mutual authentication is carried out using a handshake process such as a TLS handshake.);
generating, by the first cluster, an encrypted message comprising the data object attestation authority certificate (0057 The service mesh of the first cluster will use this signing certificate to issue leaf certificates, i.e. an encrypted message, / data object attestation authority certificate, to its proxies, 212 meaning these leaves will also be signed by the root ) and a digital signature of the first cluster, wherein the encrypted message is encrypted using a public key indicated in the cluster certificate of the second cluster ( 0055 A service mesh might only accept client certificates that have been signed by the local cluster (and include the local cluster’s “trust domain” string, i. e. by the first cluster, )), and
wherein the digital signature of the first cluster is associated with a cluster certificate of the first cluster issued by the cluster enrollment CA ( 0057 The service mesh of the first cluster will use this signing certificate to issue leaf certificates, i.e. an encrypted message, / data object attestation authority certificate, to its proxies, 212 meaning these leaves will also be signed by the root and 0058The service mesh might only accept server certificates that have been signed by the local cluster (and include the local cluster’s “trust domain” string). In this case it is possible to relax this checking to either allow certain well know cluster names, or allow any name that matches an expression, or allow any certificate that is signed by the root. ); and
providing, by the first cluster, to the second cluster, the encrypted message to be decrypted using a private key of the second cluster associated with the cluster certificate of the second cluster, and to be validated using at least the public key of the cluster enrollment CA(0067 [0069] using a client in the first cluster, originating traffic to a second cluster for processing, the second cluster having access to the root certificate; [0070] using the first service mesh, routing the traffic to the second cluster using a secure communications protocol with mutual authentication; [0071] carrying out mutual authentication between the first cluster and the second cluster using certificate chains having the root certificate; and [0072] in response to the mutual authentication being successful, routing application data from the client to the second cluster using the secure communications protocol such that the application data, i.e. encrypted message , i.e. the issue leaf certificates, i.e. an encrypted message, / data object attestation authority certificate may be processed at the second cluster to provide the service. ).
But Hockey does not disclose attestation data to the clusters,
However, Tarkhanyan discloses attestation data to the clusters,
(at 606. And fig. 6B provide attestation data of the first security manager to the tenant, and provide an attestation report to the tenant, the attestation report indicating whether attestations were successful for one or more compute nodes in the first node cluster and one or more compute nodes in the second node cluster.),
Hockey and Tarkhanyan are both considered to be analogous to the claimed invention because they are in the same field of cluster network.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hockeyto incorporate the teachings of Tarkhanyan and provide an attestation repoert.
Doing so would provide the authenticity of the report, thereby increasing report privacy.
As per claim 10. Hockey and Tarkhanyan discloses the system of claim 9,Hockey discloses the operations further comprising: prior to generating the encrypted message, enrolling the first cluster in a distributed data object attestation system, wherein enrolling the first cluster further comprises: generating a request for the cluster certificate of the first cluster, wherein the request comprises a public key of the first cluster and one or more secure environment certificates each associated with a manufacturer of a respective secure environment of the first cluster ((fig.2, [0067] Clause A. A method of processing traffic in a communications network in order to provide a service, the method comprising: [0068] using a first service mesh in the first cluster to ensure the received traffic is communicated within the first cluster using a secure communications protocol with mutual authentication accomplished using a certificate chain having a root certificate; [0069] using a client in the first cluster, originating traffic to a second cluster for processing, the second cluster having access to the root certificate; [0070] using the first service mesh, routing the traffic to the second cluster using a secure communications protocol with mutual authentication; [0071] carrying out mutual authentication between the first cluster and the second cluster using certificate chains having the root certificate; and [0072] in response to the mutual authentication being successful, routing application data from the client to the second cluster using the secure communications protocol such that the application data may be processed at the second cluster to provide the service ) ; providing the request to the cluster enrollment CA to be validated using one or more manufacturer public keys each associated with a respective secure environment certificate of the one or more secure environment certificates ([0006] A method of processing traffic to provide a service is described. A first service mesh in a first cluster is used to ensure traffic is communicated within the first cluster using a secure communications protocol with mutual authentication accomplished using a certificate chain having a root certificate. A client in the first cluster originates traffic to a second cluster for processing, the second cluster having access to the root certificate. Using the first service mesh, routing the traffic to the second cluster is done using a secure communications protocol with mutual authentication. Mutual authentication is carried out between the first cluster and the second cluster using certificate chains having the root certificate; and in response to the mutual authentication being successful, application data is routed to the second cluster using the secure communications protocol such that the application data may be processed at the second cluster to provide the service ); and receiving the cluster certificate of the first cluster from the cluster enrollment CA ( [0006] A method of processing traffic to provide a service is described. A first service mesh in a first cluster is used to ensure traffic is communicated within the first cluster using a secure communications protocol with mutual authentication accomplished using a certificate chain having a root certificate. A client in the first cluster originates traffic to a second cluster for processing, the second cluster having access to the root certificate. Using the first service mesh, routing the traffic to the second cluster is done using a secure communications protocol with mutual authentication. Mutual authentication is carried out between the first cluster and the second cluster using certificate chains having the root certificate; and in response to the mutual authentication being successful, application data is routed to the second cluster using the secure communications protocol such that the application data may be processed at the second cluster to provide the service).
As per claim 11. Hockey and Tarkhanyan discloses The system of claim 9,Hockey discloses the operations further comprising: prior to generating the encrypted message, obtaining the data object attestation authority certificate from a distributed attestation CA, wherein obtaining the data object attestation authority certificate further comprises: generating a request for the data object attestation authority certificate, the request comprising the cluster certificate of the first cluster; providing the request to the distributed attestation CA to be validated using the public key of the cluster enrollment CA(( fig.2, two clusters of the communications network of FIG. 1. FIG. 2 shows a first cluster 206 and a second cluster 218. The first cluster 206 has a control plane 208 and a plurality of units 214 together forming a first service mesh. Each of the units 214 has a proxy and a client or server. At least one of the units 214 comprises a client 210 and a proxy 212. The second cluster 218 also has a control plane 216 and a plurality of units 224 together forming a second service mesh. Each of the units 224 has a proxy 220 and a client or server 222. The first and second service meshes are independent of one another since they do not share information except for a root certificate 200 ); and receiving the data object attestation authority certificate from the distributed attestation CA ( fig.2, two clusters of the communications network of FIG. 1. FIG. 2 shows a first cluster 206 and a second cluster 218. The first cluster 206 has a control plane 208 and a plurality of units 214 together forming a first service mesh. Each of the units 214 has a proxy and a client or server. At least one of the units 214 comprises a client 210 and a proxy 212. The second cluster 218 also has a control plane 216 and a plurality of units 224 together forming a second service mesh. Each of the units 224 has a proxy 220 and a client or server 222. The first and second service meshes are independent of one another since they do not share information except for a root certificate 200).
As per claim 12. Hockey and Tarkhanyan discloses The system of claim 11, Hockey discloses wherein: the cluster enrollment CA is associated with a cluster enrollment CA certificate issued by a common root CA; and the distributed attestation CA is associated with a distributed attestation CA certificate issued by the common root CA (par 0031 fig.2, two clusters of the communications network of FIG. 1. FIG. 2 shows a first cluster 206 and a second cluster 218. The first cluster 206 has a control plane 208 and a plurality of units 214 together forming a first service mesh. Each of the units 214 has a proxy and a client or server. At least one of the units 214 comprises a client 210 and a proxy 212. The second cluster 218 also has a control plane 216 and a plurality of units 224 together forming a second service mesh. Each of the units 224 has a proxy 220 and a client or server 222. The first and second service meshes are independent of one another since they do not share information except for a root certificate 200).
As per claim 13. Hockey and Tarkhanyan discloses The system of claim 9,Tarkhayan discloses the operations further comprising: receiving a request of an entity to provide an attestation for a data object, the request comprising an identifier of the data object; identifying a storage location of the data object to be the first cluster ( 0041] Orchestrators are responsible for discovery of available orchestrators across compute fabric (e.g., including cloud and neighboring edges), addition or removal of trusted node clusters (e.g., 118, 158) to the compute fabric, allocation and deallocation of compute (and other) resources to the tenant based on the compute needs, maintaining a mapping of the tenant workload to the available trusted node cluster, and requesting an appropriate security manager (e.g., 112, 152) to verify the attestation of a node cluster against a workload execution policy (e.g., 106), or a portion thereof, associated with the tenant that requested resources. In some scenarios, the workload execution policy may be provided (e.g., by sending or identifying) by the tenant. Orchestrators are involved in facilitating the formation or establishment of node clusters (e.g., 118, 158) and a trusted group of node clusters (e.g., 130) in a secure connected compute fabric (e.g., 132), and the acceptance of the recommended compute (and other) resources into a node cluster determined by a security manager after it conducts attestation of the node cluster.); identifying one or more attributes of the data object; generating the attestation, wherein the attestation comprises the identifier of the data object, the one or more attributes of the data object, and a digital signature associated with the data object attestation authority certificate; and providing the attestation to the entity ( 0045his attestation of the pool of resources may be performed instead of individual attestations. In other embodiments, individual attestations may be performed instead of, or in addition to, the attestation of the pool of resources. Thus, in some embodiments the attestation report may also include specific information about current member devices in the node cluster (or pool of resources) attested by the security manager. In addition, in order to bring multiple node clusters (which are each assigned to the same workload) in different compute domains into a secure connected compute fabric spanning the different compute domains, security managers in the different compute domains collaborate to enforce the tenant's workload execution policy for the workload across all node clusters assigned to the workload).
As per claim 14. Hockey and Tarkhanyan discloses the system of claim 13, Hockey discloses wherein the data object comprises one or more of: a permissible usage attribute indicating for what purposes the data object may be used, an origination attribute indicating whether the data object was generated in a secure environment of the first cluster, or an export attribute indicating whether the data object may be exported from the first cluster (([0034] Suppose that the clusters of FIG. 2 are used to process traffic in order to provide a secure service. A client at unit 214 of the first cluster decides to initiate a connection to a server that is not in the same cluster. A first service mesh in the first cluster 206 is being used to ensure that traffic is communicated within the first cluster using a secure communications protocol with mutual authentication accomplished using a certificate chain having a root certificate 200. When the client at unit 214 of the first cluster initiates a connection to a server that is not in the same cluster, the client sends traffic addressed to a port at the server in the second cluster. The traffic travels via the proxy in the unit 214 due to the service mesh in the first cluster. The proxy is part of the first service mesh and so it secures traffic destined within the first cluster. However, the request is addressed to an address outside the first cluster so normally the proxy would forward the traffic in an unsecured manner. However, a configuration of the proxy has been arranged to ensure the traffic is sent using a secure protocol with mutual authentication. The configuration is static and agnostic to the topology of the destination cluster. The second cluster 201 has access to the root certificate 200. Mutual authentication is carried out between the first cluster 206 and the second cluster 218 using certificate chains having the root certificate 200. If the mutual authentication is successful the client in the first cluster proceeds to send application data to the server in the second cluster over the secure, mutually authenticated route. The control plane is optionally modified so that the first cluster does not access any other services using the specified port ).
As per claim 15. Hockey discloses A non-transitory computer-readable medium comprising instructions that, when executed by a processing device associated with a first cluster of secure environments (0055 computer storage media (memory 508) is shown within the computing-based device 500 it will be appreciated that the storage), cause the processing device to perform operations comprising:
receiving, by a first cluster of secure environments comprising one or more processing devices, a request to provide a data object attestation authority certificate to a second cluster of secure environments ( fig.2, 0033 Certificate chains are formed from the root certificate whereby the first cluster has a first cluster certificate 202 and the second cluster has a second cluster certificate 204, wherein the cluster1 206 received a request of the cluster 1 certificate 202, i.e. attestation authority certificate from the Root certificate 200 for authenticate the cluster 2 0084 0087] a client in the first cluster, the client originating traffic to a second cluster for processing, the second cluster having access to the root certificate; [0089] route the traffic to the second cluster using a secure communications protocol with mutual authentication; ) the request comprising a cluster certificate of the second cluster issued by a cluster enrollment certificate authority(CA) (0033 The control plane 208 of the first cluster 206 uses the first cluster certificate to issue leaf certificates to its proxies 212 such that the leaf certificates are also ultimately signed by the root certificate 200, i.e. CA, that sends the request that includes the cluster1 certificate 202. And 0046 The service mesh at the first cluster is used to ensure 300 traffic within the first cluster is communicated within the first cluster using a secure communications protocol with mutual authentication accomplished using a root certificate. );
validating, by the first cluster, the cluster certificate of the second cluster using a public key of the cluster enrollment CA (0036 The proxy in the first cluster validates the certificate chain of the proxy in the second cluster. The proxy in the second cluster validates the certificate chain of the proxy in the first cluster. And 0047 A client in a unit in the first cluster decides to send 302 traffic to a server in the second cluster and so sends traffic to an address of a port at the server in the second cluster. [0048] The first cluster carries out 306 mutual authentication with the second cluster. More specifically, a client in a unit of the first cluster which is configured to forward the traffic to a server in a unit in the second cluster establishes a communication session with the server. As part of the establishment of the communication session, mutual authentication is carried out using a handshake process such as a TLS handshake.);
generating, by the first cluster, an encrypted message comprising the data object attestation authority certificate (0057 The service mesh of the first cluster will use this signing certificate to issue leaf certificates, i.e. an encrypted message, / data object attestation authority certificate, to its proxies, 212 meaning these leaves will also be signed by the root ) and a digital signature of the first cluster, wherein the encrypted message is encrypted using a public key indicated in the cluster certificate of the second cluster ( 0055 A service mesh might only accept client certificates that have been signed by the local cluster (and include the local cluster’s “trust domain” string, i. e. by the first cluster, )), and
wherein the digital signature of the first cluster is associated with a cluster certificate of the first cluster issued by the cluster enrollment CA ( 0057 The service mesh of the first cluster will use this signing certificate to issue leaf certificates, i.e. an encrypted message, / data object attestation authority certificate, to its proxies, 212 meaning these leaves will also be signed by the root and 0058The service mesh might only accept server certificates that have been signed by the local cluster (and include the local cluster’s “trust domain” string). In this case it is possible to relax this checking to either allow certain well know cluster names, or allow any name that matches an expression, or allow any certificate that is signed by the root); and
providing, by the first cluster, to the second cluster, the encrypted message to be decrypted using a private key of the second cluster associated with the cluster certificate of the second cluster, and to be validated using at least the public key of the cluster enrollment CA(0067 [0069] using a client in the first cluster, originating traffic to a second cluster for processing, the second cluster having access to the root certificate; [0070] using the first service mesh, routing the traffic to the second cluster using a secure communications protocol with mutual authentication; [0071] carrying out mutual authentication between the first cluster and the second cluster using certificate chains having the root certificate; and [0072] in response to the mutual authentication being successful, routing application data from the client to the second cluster using the secure communications protocol such that the application data, i.e. encrypted message , i.e. the issue leaf certificates, i.e. an encrypted message, / data object attestation authority certificate may be processed at the second cluster to provide the service. ).
But Hockey does not disclose attestation data to the clusters,
However, Tarkhanyan discloses attestation data to the clusters,
(at 606. And fig. 6B provide attestation data of the first security manager to the tenant, and provide an attestation report to the tenant, the attestation report indicating whether attestations were successful for one or more compute nodes in the first node cluster and one or more compute nodes in the second node cluster.),
Hockey and Tarkhanyan are both considered to be analogous to the claimed invention because they are in the same field of cluster network.
Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Hockeyto incorporate the teachings of Tarkhanyan and provide an attestation repoert.
Doing so would provide the authenticity of the report, thereby increasing report privacy.
As per claim 16. Hockey and Tarkhanyan discloses the non-transitory computer-readable medium of claim 15, the operations further comprising: prior to generating the encrypted message, enrolling the first cluster in a distributed data object attestation system, wherein enrolling the first cluster further comprises: generating a request for the cluster certificate of the first cluster, wherein the request comprises a public key of the first cluster and one or more secure environment certificates each associated with a manufacturer of a respective secure environment of the first cluster (fig.2, [0067] Clause A. A method of processing traffic in a communications network in order to provide a service, the method comprising: [0068] using a first service mesh in the first cluster to ensure the received traffic is communicated within the first cluster using a secure communications protocol with mutual authentication accomplished using a certificate chain having a root certificate; [0069] using a client in the first cluster, originating traffic to a second cluster for processing, the second cluster having access to the root certificate; [0070] using the first service mesh, routing the traffic to the second cluster using a secure communications protocol with mutual authentication; [0071] carrying out mutual authentication between the first cluster and the second cluster using certificate chains having the root certificate; and [0072] in response to the mutual authentication being successful, routing application data from the client to the second cluster using the secure communications protocol such that the application data may be processed at the second cluster to provide the service. ); providing the request to the cluster enrollment CA to be validated using one or more manufacturer public keys each associated with a respective secure environment certificate of the one or more secure environment certificates ( [0006] A method of processing traffic to provide a service is described. A first service mesh in a first cluster is used to ensure traffic is communicated within the first cluster using a secure communications protocol with mutual authentication accomplished using a certificate chain having a root certificate. A client in the first cluster originates traffic to a second cluster for processing, the second cluster having access to the root certificate. Using the first service mesh, routing the traffic to the second cluster is done using a secure communications protocol with mutual authentication. Mutual authentication is carried out between the first cluster and the second cluster using certificate chains having the root certificate; and in response to the mutual authentication being successful, application data is routed to the second cluster using the secure communications protocol such that the application data may be processed at the second cluster to provide the service.); and receiving the cluster certificate of the first cluster from the cluster enrollment CA ( [0006] A method of processing traffic to provide a service is described. A first service mesh in a first cluster is used to ensure traffic is communicated within the first cluster using a secure communications protocol with mutual authentication accomplished using a certificate chain having a root certificate. A client in the first cluster originates traffic to a second cluster for processing, the second cluster having access to the root certificate. Using the first service mesh, routing the traffic to the second cluster is done using a secure communications protocol with mutual authentication. Mutual authentication is carried out between the first cluster and the second cluster using certificate chains having the root certificate; and in response to the mutual authentication being successful, application data is routed to the second cluster using the secure communications protocol such that the application data may be processed at the second cluster to provide the service.).
As per claim 17. Hockey and Tarkhanyan discloses The non-transitory computer-readable medium of claim 15, Hockey discloses the operations further comprising: prior to generating the encrypted message, obtaining the data object attestation authority certificate from a distributed attestation CA, wherein obtaining the data object attestation authority certificate further comprises: generating a request for the data object attestation authority certificate, the request comprising the cluster certificate of the first cluster; providing the request to the distributed attestation CA to be validated using the public key of the cluster enrollment CA; and receiving the data object attestation authority certificate from the distributed attestation CA (( fig.2, two clusters of the communications network of FIG. 1. FIG. 2 shows a first cluster 206 and a second cluster 218. The first cluster 206 has a control plane 208 and a plurality of units 214 together forming a first service mesh. Each of the units 214 has a proxy and a client or server. At least one of the units 214 comprises a client 210 and a proxy 212. The second cluster 218 also has a control plane 216 and a plurality of units 224 together forming a second service mesh. Each of the units 224 has a proxy 220 and a client or server 222. The first and second service meshes are independent of one another since they do not share information except for a root certificate 200 ); providing the request to the distributed attestation CA to be validated using the public key of the cluster enrollment CA; and receiving the data object attestation authority certificate from the distributed attestation CA (fig.2, two clusters of the communications network of FIG. 1. FIG. 2 shows a first cluster 206 and a second cluster 218. The first cluster 206 has a control plane 208 and a plurality of units 214 together forming a first service mesh. Each of the units 214 has a proxy and a client or server. At least one of the units 214 comprises a client 210 and a proxy 212. The second cluster 218 also has a control plane 216 and a plurality of units 224 together forming a second service mesh. Each of the units 224 has a proxy 220 and a client or server 222. The first and second service meshes are independent of one another since they do not share information except for a root certificate 200).
As per claim 18. Hockey and Tarkhanyan discloses The non-transitory computer-readable medium of claim 17, Hockey discloses wherein: the cluster enrollment CA is associated with a cluster enrollment CA certificate issued by a common root CA; and the distributed attestation CA is associated with a distributed attestation CA certificate issued by the common root CA (( par 0031 fig.2, two clusters of the communications network of FIG. 1. FIG. 2 shows a first cluster 206 and a second cluster 218. The first cluster 206 has a control plane 208 and a plurality of units 214 together forming a first service mesh. Each of the units 214 has a proxy and a client or server. At least one of the units 214 comprises a client 210 and a proxy 212. The second cluster 218 also has a control plane 216 and a plurality of units 224 together forming a second service mesh. Each of the units 224 has a proxy 220 and a client or server 222. The first and second service meshes are independent of one another since they do not share information except for a root certificate 200).
As per claim 19. Hockey and Tarkhanyan discloses The non-transitory computer-readable medium of claim 15, Tarkhanyan discloses the operations further comprising: receiving a request of an entity to provide an attestation for a data object, the request comprising an identifier of the data object (0041] Orchestrators are responsible for discovery of available orchestrators across compute fabric (e.g., including cloud and neighboring edges), addition or removal of trusted node clusters (e.g., 118, 158) to the compute fabric, allocation and deallocation of compute (and other) resources to the tenant based on the compute needs, maintaining a mapping of the tenant workload to the available trusted node cluster, and requesting an appropriate security manager (e.g., 112, 152) to verify the attestation of a node cluster against a workload execution policy (e.g., 106), or a portion thereof, associated with the tenant that requested resources. In some scenarios, the workload execution policy may be provided (e.g., by sending or identifying) by the tenant. Orchestrators are involved in facilitating the formation or establishment of node clusters (e.g., 118, 158) and a trusted group of node clusters (e.g., 130) in a secure connected compute fabric (e.g., 132), and the acceptance of the recommended compute (and other) resources into a node cluster determined by a security manager after it conducts attestation of the node cluster. ); identifying a storage location of the data object to be the second cluster ( 0041] Orchestrators are responsible for discovery of available orchestrators across compute fabric (e.g., including cloud and neighboring edges), addition or removal of trusted node clusters (e.g., 118, 158) to the compute fabric, allocation and deallocation of compute (and other) resources to the tenant based on the compute needs, maintaining a mapping of the tenant workload to the available trusted node cluster, and requesting an appropriate security manager (e.g., 112, 152) to verify the attestation of a node cluster against a workload execution policy (e.g., 106), or a portion thereof, associated with the tenant that requested resources. In some scenarios, the workload execution policy may be provided (e.g., by sending or identifying) by the tenant. Orchestrators are involved in facilitating the formation or establishment of node clusters (e.g., 118, 158) and a trusted group of node clusters (e.g., 130) in a secure connected compute fabric (e.g., 132), and the acceptance of the recommended compute (and other) resources into a node cluster determined by a security manager after it conducts attestation of the node cluster.); obtaining one or more attributes of the data object from the second cluster; generating the attestation, wherein the attestation comprises the identifier of the data object, the one or more attributes of the data object, and a digital signature associated with the data object attestation authority certificate; and providing the attestation to the entity( 0041] Orchestrators are responsible for discovery of available orchestrators across compute fabric (e.g., including cloud and neighboring edges), addition or removal of trusted node clusters (e.g., 118, 158) to the compute fabric, allocation and deallocation of compute (and other) resources to the tenant based on the compute needs, maintaining a mapping of the tenant workload to the available trusted node cluster, and requesting an appropriate security manager (e.g., 112, 152) to verify the attestation of a node cluster against a workload execution policy (e.g., 106), or a portion thereof, associated with the tenant that requested resources. In some scenarios, the workload execution policy may be provided (e.g., by sending or identifying) by the tenant. Orchestrators are involved in facilitating the formation or establishment of node clusters (e.g., 118, 158) and a trusted group of node clusters (e.g., 130) in a secure connected compute fabric (e.g., 132), and the acceptance of the recommended compute (and other) resources into a node cluster determined by a security manager after it conducts attestation of the node cluster.).
As per claim 20. Hockey and Tarkhanyan discloses The non-transitory computer-readable medium of claim 15, Hockey discloses wherein the encrypted message is to be further validated using at least the cluster certificate of the first cluster(0057 The service mesh of the first cluster will use this signing certificate to issue leaf certificates, i.e. an encrypted message, / data object attestation authority certificate, to its proxies, 212 meaning these leaves will also be signed by the root and 0058The service mesh might only accept server certificates that have been signed by the local cluster (and include the local cluster’s “trust domain” string)).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABU S SHOLEMAN whose telephone number is (571)270-7314. The examiner can normally be reached EST: 9am-5pm.
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, JORGE ORTIZ CRIADO can be reached at 571-272-7624. 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.
/ABU S SHOLEMAN/Primary Examiner, Art Unit 2496
Prosecution Insights