DETAILED ACTION
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 Amendment
The amendment filed 05/05/2026 has been entered. Claims 1, 6, 8-10, 14-16 and 19-20 been amended. No Claims have been newly added. No Claims has been/remains canceled. Claims 1-20 remain pending in the application.
Applicant arguments towards to Specification have overcome the objections previously set forth in the Non-Final Office Action mailed on 02/12/2026. The objection has been withdrawn in view of the amended Specification.
Applicant amendments to the Claims have overcome the objections previously set forth in the Non-Final Office Action mailed on 02/12/2026. The objection has been withdrawn in view of the amended Claims.
Response to Arguments
Regarding Applicant’s arguments, on page 11-15 of the remark filed on 05/05/2026, on the newly amended limitations of independent Claims 1: “provide, by the sidecar, the client signed key to the microservice container by injecting the client signed key into the microservice container; and.”, arguments are not persuasive.
Applicant argues on Pages 12-13 that the cited references fail to teach provide, by the sidecar, the client signed key to the microservice container by injecting the client signed key into the microservice container. Applicant’s interpretation of the reference has been noted; however, examiner respectfully disagrees. Examiner states in the instant application on Par. (0024) the specification describes “injection” and “key injection to the microservice” as a passing of a service into the client that uses it. Therefore, it will be broadly and reasonably interpreted in light of the specification that “injecting the client signed key into the microservice container” refers to the passing or providing of the key as a service. Cannata teaches on Col. 6 lines 60-67 and Col. 7 lines 1-35 a sidecar providing a service to a microservice container by providing or passing the client signed key. Therefore, the rejection is maintained.
However, with regards to Applicant’s arguments, on page 11-15 of the remark filed on 05/05/2026, on the newly amended limitations of independent claim 1 “initialize a sidecar for the microservice container in a trust domain (TD) of a confidential compute architecture.”, arguments are persuasive.
Therefore, the 35 U.S.C. 103 rejection over Amaro et al. (U.S Pub. No. 20220405116 (see U.S provisional application 63/211,535)) and Antonas et al. (U.S Pub. No. 20220006862) further in view of Cannata et al. (U.S No. 11431513), has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made under 35 U.S.C. § 103 in view of the following prior art: Smith et al. (U.S Pub. No. 20200127980) in conjunction Amaro et al. (U.S Pub. No. 20220405116 (see U.S provisional application 63/211,535)) and Antonas et al. (U.S Pub. No. 20220006862) and Cannata et al. (U.S No. 11431513)). Please refer to the 35 U.S.C. 103 section below for a detailed explanation.
For the reasons stated above and the new ground(s) of rejection under 35 U.S.C. 103 below, Examiner respectfully disagrees with Applicant’s argument, see Applicant’s Remarks Page 11-15, regarding allowance of the application. Examiner asserts that claims 1-20 are rejected for the reasons stated above in conjunction with the new ground(s) of rejection under 35 U.S.C. 103 below.
Conclusion: Amaro-Smith-Antonas-Cannata teaches the aforementioned limitations of independent claims and 1, 10 and 16 rendering the claim limitations obvious before the effective date of the claimed invention.
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.
Claim(s) 1, 3, 5, 10, 12, 13, 16 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amaro et al. (U.S Pub. No. 20220405116 (see U.S provisional application 63/211,535), hereinafter referred to as “Amaro”), Smith et al. (U.S Pub. No. 20200127980, hereinafter referred to as “Smith”) and Antonas et al. (U.S Pub. No. 20220006862, hereinafter referred to as “Antonas”) further in view of Cannata et al. (U.S No. 11431513, hereinafter referred to as “Cannata”).
In regards to Claim 1, Amaro teaches an apparatus comprising: (Par. (0011-0012); nodes and computing devices)
one or more processors to: (Par. (0011-0012); processors with nodes and layer components)
generate, using a cloud-to-personal computer (PC) extension framework (CPEF) edge component, a root key of the CPEF edge component, (Par. (0114-0115 and 0136); a cloud-to-personal computer (PC) extension framework (CPEF) (cloud computing with edge connectivity and layer components/nodes)), (Par. (0012 and 0023; CPEF edge component (SDCS network with layer components executed on nodes)), (Par. (0246); generate a root key of CPEF edge component (generated pubic key associated with certificate and certificate authority by SDCS system, layers, container and nodes))
wherein the CPEF edge component is trusted by the one or more processors; (Par. (0246 and 0259); SDCS system with components and nodes associated with certificate authority))
deploy, using the CPEF edge component, a microservice container to locally host functionality of a microservice of an application, (Par. (0241-0245); microservices implemented and deploying containers), (Par. (0163-0164); host functionality of a microservice of an application (microservices executing in containers))
wherein the application is hosted remotely from the apparatus; (Par. (0006); applications being executing on one or more remote computing devices))
Amaro does not explicitly teach initialize a sidecar for the microservice container in a trust domain (TD) of a confidential compute architecture; generate, by the sidecar, a client signed key using at least one of the root key and a hostname of the microservice to sign the client signed key; provide, by the sidecar, the client signed key to the microservice container by injecting the client signed key into the microservice container; and redirect requests for the microservice to the microservice container, the requests originating from an accessing application of the apparatus, the requests redirected through a secure communication channel that is trusted based on the client signed key.
Wherein Smith teaches initialize a sidecar for the microservice container in a trust domain (TD) of a confidential compute architecture; (Par. (0132); microservice and sidecar with trusted domain of trusted execution environment. For instance, as disclosed in par. (0133), there may be a local secure path between the microservice and sidecar based on local cryptographic keys (e.g., established with a DICE architecture) where the microservice is provisioned with a policy that allows it to attest and trust the sidecar. The side-car also may be provisioned with a policy that allows it to attest and trust the microservice. Also, it will be understood that the microservice and sidecar may be bound or securely associated in other ways, whether using a hypervisor, microcode, or other features to establish a trusted binding/path between the microservice and sidecar.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro to incorporate the teaching of Smith to utilize the above feature because of the analogous concept of microservice containers and authentication techniques in cloud computing, with the motivation of improving compliance and security in cloud-like distribution services to create trust and end-to-end security protection. (Smith Par. (0003-0006))
Amaro and Smith do not explicitly teach generate, by the sidecar, a client signed key using at least one of the root key and a hostname of the microservice to sign the client signed key; provide, by the sidecar, the client signed key to the microservice container by injecting the client signed key into the microservice container; and redirect requests for the microservice to the microservice container, the requests originating from an accessing application of the apparatus, the requests redirected through a secure communication channel that is trusted based on the client signed key.
Wherein Antonas teaches redirect requests for the microservice to the microservice container, (Par. (0087); proxy redirects request for microservice (microservice associated with request to manipulate stored object from container) to microservice container (user with container)), (Par. (0072); microservice container))
the requests originating from an accessing application of the apparatus, (Par. (0087); requests originating from (request from a user) an accessing application of the apparatus (request from user who has access to application and has ability to manipulate stored object of container)), (Par. (0083-0085 and 0090); request from user corresponding to application that gives access to manipulate))
the requests redirected through a secure communication channel that is trusted based on the client … key. (Par. (0087) request to redirect through secure communication (object proxy gateway) based on user keys)), (Par. (0081-0082 and 0085); secure communication channel that is trusted (pre-signed URL and object proxy services that secures object when HTTP is redirected))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro and Smith to incorporate the teaching of Antonas to utilize the above feature because of the analogous concept of application and mapping to a microservice containerized environment using cloud computing, with the motivation of regulating access of sensitive information in the cloud computing environment and facilitating using proxy and redirect appropriate access to containers to help improve performance and success of users to retrieve data more effectively. (Antonas Par. (0002-0004, 0008 and 0068)
Amaro, Smith and Antonas do not explicitly teach generate, by the sidecar, a client signed key using at least one of the root key and a hostname of the microservice; provide, by the sidecar, the client signed key to the microservice container; and client signed key
Wherein Cannata teaches generate, by the sidecar, a client signed key using at least one of the root key and a hostname of the microservice to sign the client signed key; (Col. 6 lines 5-45 and Col. 6 lines 60-6; sidecar (gateway node) generates signed client key (generates signed access token from user) using at least one of the root key (public key associated with certificate authority)), (Figure 4 label 300; “name” and Col. 8 lines 20-45; client signed key (signed access token) using at least one of hostname of microservice (payload with name)), (Col. 7 lines 25-45; a client signed key using at least one of hostname of microservice (namespace of microservice associated with signed access token)), (Col. 6 lines 45-60; to sign the client key (signed access token that includes public key is sent), (Examiner Note: By using the phrase “at least one of} followed by “root key and a hostname”, the applicant is reciting an optional limitation with the phrase “at least one of”. Therefore it will be broadly and reasonably interpreted in light of the claims that the client signed key will only need to use either the root key or a hostname of the microservice).
provide, by the sidecar, the client signed key to the microservice container by injecting the client signed key into the microservice container; and (Col. 6 lines 60-67 and Col. 7 lines 1-35; sidecar (gateway node) provides signed key (signed access token to microservice container))(Examiner Note: In the instant application on Par. (0024) the specification describes “injection” and “key injection to the microservice” as a passing of a service into the client that uses it. Therefore it will be broadly and reasonably interpreted in light of the specification that “injecting the client signed key into the microservice container” refers to the passing or providing of the key as a service)
client signed key (Col. 8 lines 45-67; access is granted and established connection based on signed token)), (Col. 2 lines 38-50; client signed key (signing of access token))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith and Antonas to incorporate the teaching of Cannata to utilize the above feature because of the analogous concept of application and mapping to a microservice containerized environment using cloud computing, with the motivation of implementing a process in which microservice containers evaluate access and use proxy servers and policy management to validate access request prevent bottlenecking and promote high responsiveness and authentication for high impact and performance. (Cannata Col. 1 lines 15-37 and 45-67))
In regards to Claim 3, the combination of Amaro, Smith, Antonas and Cannata teach the apparatus of claim 1, Smith further teaches wherein the sidecar is protected by a confidential compute architecture. (Par. (0132); microservice and sidecar with trusted domain of trusted execution environment. For instance, in par. (0133), there may be a local secure path between the microservice and sidecar based on local cryptographic keys (e.g., established with a DICE architecture) where the microservice is provisioned with a policy that allows it to attest and trust the sidecar. The side-car also may be provisioned with a policy that allows it to attest and trust the microservice. Also, it will be understood that the microservice and sidecar may be bound or securely associated in other ways, whether using a hypervisor, microcode, or other features to establish a trusted binding/path between the microservice and sidecar.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Antonas and Cannata to incorporate the teaching of Smith to utilize the above feature because of the analogous concept of microservice containers and authentication techniques in cloud computing, with the motivation of improving compliance and security in cloud-like distribution services to create trust and end-to-end security protection. (Smith Par. (0003-0006))
In regards to Claim 5, the combination of Amaro, Smith, Antonas and Cannata teach the apparatus of claim 1, Antonas further teaches wherein the accessing application comprises at least one of a web application (webapp) or a browser application. (Par. (0062 and 0080-0081); web browser and web resource that grants access to container with application in URL))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith and Cannata to incorporate the teaching of Antonas to utilize the above feature because of the analogous concept of application and mapping to a microservice containerized environment using cloud computing, with the motivation of utilizing web servers and browsers to allow applications within containers and proxy servers to retrieve information and use web addresses to link to specific location for valid access. (Antonas Par. (0080-0081)).
In regards to Claim 10, Amaro teaches a method comprising: generating, by one or more processors using a cloud-to-personal computer (PC) extension framework (CPEF) edge component, a root key of the CPEF edge component, (Par. (0114-0115 and 0136); a cloud-to-personal computer (PC) extension framework (CPEF) (cloud computing with edge connectivity and layer components/nodes)), (Par. (0012-0113);processors with nodes and layer components), (Par. (0012 and 0023; CPEF edge component (SDCS network with layer components executed on nodes)), (Par. (0246); generate a root key of CPEF edge component (generated pubic key associated with certificate and certificate authority by SDCS system, layers, container and nodes))
wherein the CPEF edge component is trusted by the one or more processors; (Par. (0246 and 259); SDCS system with components and nodes associated with certificate authority))
deploying, using the CPEF edge component, a microservice container to locally host functionality of a microservice of an application, (Par. (0241-0245); microservices implemented and deploying containers ), (Par. (0162-0163); host functionality of a microservice of an application (microservices executing in containers))
wherein the application is hosted remotely from a computing device of the one or more processors; (Par. (0006); applications being executing on one or more remote computing devices))
Amaro does not explicitly teach initializing a sidecar for the microservice container in a trust domain (TD) of a confidential compute architecture; generating, by the sidecar, a client signed key using at least one of the root key and a hostname of the microservice to sign the client signed key; providing, by the sidecar, the client signed key to the microservice container by injecting the client signed key into the microservice container; redirecting requests for the microservice to the microservice container, the requests originating from an accessing application of the computing device, the requests redirected through a secure communication channel that is trusted based on the client signed key.
Wherein Smith teaches initializing a sidecar for the microservice container in a trust domain (TD) of a confidential compute architecture; (Par. (0132); microservice and sidecar with trusted domain of trusted execution environment. For instance, as disclosed in par. (0133), there may be a local secure path between the microservice and sidecar based on local cryptographic keys (e.g., established with a DICE architecture) where the microservice is provisioned with a policy that allows it to attest and trust the sidecar. The side-car also may be provisioned with a policy that allows it to attest and trust the microservice. Also, it will be understood that the microservice and sidecar may be bound or securely associated in other ways, whether using a hypervisor, microcode, or other features to establish a trusted binding/path between the microservice and sidecar.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro to incorporate the teaching of Smith to utilize the above feature because of the analogous concept of microservice containers and authentication techniques in cloud computing, with the motivation of improving compliance and security in cloud-like distribution services to create trust and end-to-end security protection. (Smith Par. (0003-0006))
Amaro and Smith do not explicitly teach generating, by the sidecar, a client signed key using at least one of the root key and a hostname of the microservice to sign the client signed key; providing, by the sidecar, the client signed key to the microservice container by injecting the client signed key into the microservice container; redirecting requests for the microservice to the microservice container, the requests originating from an accessing application of the computing device, the requests redirected through a secure communication channel that is trusted based on the client signed key.
Wherein Antonas teaches redirecting requests for the microservice to the microservice container, (Par. (0087); proxy redirects request for microservice (microservice associated with request to manipulate stored object from container) to microservice container (user with container)), (Par. (0072); microservice container))
the requests originating from an accessing application of the computing device, (Par. (0087); request from a user to manipulate stored object of container)), (Par. (0083-0085 and 0090); request from user corresponding to application that gives access to manipulate))
the requests redirected through a secure communication channel that is trusted based on the …key. (Par. (0087) request to redirect through secure communication (object proxy gateway) based on user keys)), (Par. (0081-0082 and 0085); secure communication channel that is trusted (pre-signed URL and object proxy services that secures object when HTTP is redirected))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro and Smith to incorporate the teaching of Antonas to utilize the above feature because of the analogous concept of application and mapping to a microservice containerized environment using cloud computing, with the motivation of regulating access of sensitive information in the cloud computing environment and facilitating using proxy and redirect appropriate access to containers to help improve performance and success of users to retrieve data more effectively. (Antonas Par. (0002-0004, 0008 and 0068)
Amaro and Antonas do not explicitly teach generating, by the sidecar, a client signed key using at least one of the root key and a hostname of the microservice to sign the client signed key; providing, by the sidecar, the client signed key to the microservice container by injecting the client signed key into the microservice container; and client signed key
Wherein Cannata teaches generating, by the sidecar, a client signed key using at least one of the root key and a hostname of the microservice to sign the client signed key; (Col. 6 lines 5-45 and Col. 6 lines 60-6; sidecar (gateway node) generates signed client key (generates signed access token from user) using at least one of the root key (public key associated with certificate authority)), (Figure 4 label 300; “name” and Col. 8 lines 20-45; client signed key (signed access token) using at least one of hostname of microservice (payload with name)), (Col. 7 lines 25-45; a client signed key using at least one of hostname of microservice (namespace of microservice associated with signed access token), (Col. 6 lines 45-60; to sign the client key (signed access token that includes public key is sent), (Examiner Note: By using the phrase “at least one of} followed by “root key and a hostname”, the applicant is reciting an optional limitation with the phrase “at least one of”. Therefore, it will be broadly and reasonably interpreted in light of the claims that the client signed key will only need to use either the root key or a hostname of the microservice).
providing, by the sidecar, the client signed key to the microservice container by injecting the client signed key into the microservice container; and (Col. 6 lines 60-67 and Col. 7 lines 1-35; sidecar (gateway node) provides signed key (signed access token to microservice container)). (Examiner Note: In the instant application on Par. (0024) the specification describes “injection” and “key injection to the microservice” as a passing of a service into the client that uses it. Therefore, it will be broadly and reasonably interpreted in light of the specification that “injecting the client signed key into the microservice container” refers to the passing or providing of the key as a service)
client signed key (Col. 8 lines 45-67; access is granted and established connection based on signed token)), (Col. 2 lines 38-50; client signed key (signing of access token))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith and Antonas to incorporate the teaching of Cannata to utilize the above feature because of the analogous concept of application and mapping to a microservice containerized environment using cloud computing, with the motivation of implementing a process in which microservice containers evaluate access and use proxy servers and policy management to validate access request prevent bottlenecking and promote high responsiveness and authentication for high impact and performance. (Cannata Col. 1 lines 15-37 and 45-67))
In regards to Claim 12, the combination of Amaro, Smith, Antonas and Cannata teach the method of claim 10, Smith further teaches wherein the sidecar is protected by a confidential compute architecture. (Par. (0132); microservice and sidecar with trusted domain of trusted execution environment. For instance, in par. (0133), there may be a local secure path between the microservice and sidecar based on local cryptographic keys (e.g., established with a DICE architecture) where the microservice is provisioned with a policy that allows it to attest and trust the sidecar. The side-car also may be provisioned with a policy that allows it to attest and trust the microservice. Also, it will be understood that the microservice and sidecar may be bound or securely associated in other ways, whether using a hypervisor, microcode, or other features to establish a trusted binding/path between the microservice and sidecar.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Antonas and Cannata to incorporate the teaching of Smith to utilize the above feature because of the analogous concept of microservice containers and authentication techniques in cloud computing, with the motivation of improving compliance and security in cloud-like distribution services to create trust and end-to-end security protection. (Smith Par. (0003-0006))
In regards to Claim 13, the combination of Amaro, Smith Antonas and Cannata teach the method of claim 10, Antonas further teaches wherein the accessing application comprises at least one of a web application (webapp) or a browser application. (Par. (0062 and 0080-0081); web browser and web resource that grants access to container with application in URL))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith and Cannata to incorporate the teaching of Antonas to utilize the above feature because of the analogous concept of application and mapping to a microservice containerized environment using cloud computing, with the motivation of utilizing web servers and browsers to allow applications within containers and proxy servers to retrieve information and use web addresses to link to specific location for valid access (Antonas Par. (0080-0081)).
In regards to Claim 16, Amaro teaches a non-transitory computer-readable storage medium having stored thereon executable computer program instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: (Par. (0215-0216); non-transitory computer readable media and processor))
generating, by the one or more processors using a cloud-to-personal computer (PC) extension framework (CPEF) edge component, a root key of the CPEF edge component, (Par. (0114-0115 and 0136); a cloud-to-personal computer (PC) extension framework (CPEF) (cloud computing with edge connectivity and layer components/nodes)), (Par. (0012 and 0023; CPEF edge component (SDCS network with layer components executed on nodes)), (Par. (0246); generate a root key of CPEF edge component (generated pubic key associated with certificate and certificate authority by SDCS system, layers, container and nodes))
wherein the CPEF edge component is trusted by the one or more processors; (Par. (0246 and 259); SDCS system with components and nodes associated with certificate authority))
deploying, using the CPEF edge component, a microservice container to locally host functionality of a microservice of an application, (Par. (0241-0245); microservices implemented and deploying containers ), (Par. (0162-0163); host functionality of a microservice of an application (microservices executing in containers))
wherein the application is hosted remotely from a computing device of the one or more processors; (Par. (0006); applications being executing on one or more remote computing devices))
Amaro does not explicitly teach initializing a sidecar for the microservice container in a trust domain (TD) of a confidential compute architecture; generating, by the sidecar, a client signed key using at least one of the root key and a hostname of the microservice to sign the client signed key; providing, by the sidecar, the client signed key to the microservice container by injecting the client signed key into the microservice container; and redirecting requests for the microservice to the microservice container, the requests originating from an accessing application of the computing device, the requests redirected through a secure communication channel that is trusted based on the client signed key.
Wherein Smith teaches initializing a sidecar for the microservice container in a trust domain (TD) of a confidential compute architecture; (Par. (0132); microservice and sidecar with trusted domain of trusted execution environment. For instance, as disclosed in par. (0133), there may be a local secure path between the microservice and sidecar based on local cryptographic keys (e.g., established with a DICE architecture) where the microservice is provisioned with a policy that allows it to attest and trust the sidecar. The side-car also may be provisioned with a policy that allows it to attest and trust the microservice. Also, it will be understood that the microservice and sidecar may be bound or securely associated in other ways, whether using a hypervisor, microcode, or other features to establish a trusted binding/path between the microservice and sidecar.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro to incorporate the teaching of Antonas to utilize the above feature because of the analogous concept of microservice containers and authentication techniques in cloud computing, with the motivation of improving compliance and security in cloud-like distribution services to create trust and end-to-end security protection. (Smith Par. (0003-0006))
Amaro and Smith do not explicitly teach generating, by the sidecar, a client signed key using at least one of the root key and a hostname of the microservice to sign the client signed key; providing, by the sidecar, the client signed key to the microservice container by injecting the client signed key into the microservice container; and redirecting requests for the microservice to the microservice container, the requests originating from an accessing application of the computing device, the requests redirected through a secure communication channel that is trusted based on the client signed key.
Wherein Antonas teaches redirecting requests for the microservice to the microservice container, (Par. (0087); proxy redirects request for microservice (microservice associated with request to manipulate stored object from container) to microservice container (user with container)), (Par. (0072)
the requests originating from an accessing application of the computing device, (Par. (0087); request from a user to manipulate stored object of container)), (Par. (0083-0085 and 0090); request from user corresponding to application that gives access to manipulate))
the requests redirected through a secure communication channel that is trusted based on the … key. (Par. (0087) request to redirect through secure communication (object proxy gateway) based on user keys)), (Par. (0081-0082 and 0085); secure communication channel that is trusted (pre-signed URL and object proxy services that secures object when HTTP is redirected))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro and Smith to incorporate the teaching of Antonas to utilize the above feature because of the analogous concept of application and mapping to a microservice containerized environment using cloud computing, with the motivation of regulating access of sensitive information in the cloud computing environment and facilitating using proxy and redirect appropriate access to containers to help improve performance and success of users to retrieve data more effectively. (Antonas Par. (0002-0004, 0008 and 0068)
Amaro, Smith and Antonas do not explicitly teach generating, by the sidecar, a client signed key using at least one of the root key and a hostname of the microservice to sign the client signed key; providing, by the sidecar, the client signed key to the microservice container by injecting the client signed key into the microservice container; and client signed key
Wherein Cannata teaches generating, by the sidecar, a client signed key using at least one of the root key and a hostname of the microservice to sign the client signed key; (Col. 6 lines 5-45 and Col. 6 lines 60-6; sidecar (gateway node) generates signed client key (generates signed access token from user) using at least one of the root key (public key associated with certificate authority)), (Figure 4 label 300; “name” and Col. 8 lines 20-45; client signed key (signed access token) using at least one of hostname of microservice (payload with name)), (Col. 7 lines 25-45; a client signed key using at least one of hostname of microservice (namespace of microservice associated with signed access token), (Col. 6 lines 45-60; to sign the client key (signed access token that includes public key is sent), (Examiner Note: By using the phrase “at least one of} followed by “root key and a hostname”, the applicant is reciting an optional limitation with the phrase “at least one of”. Therefore it will be broadly and reasonably interpreted in light of the claims that the client signed key will only need to use either the root key or a hostname of the microservice).
providing, by the sidecar, the client signed key to the microservice container by injecting the client signed key into the microservice container; and (Col. 6 lines 60-67 and Col. 7 lines 1-35; sidecar (gateway node) provides signed key (signed access token to microservice container))
client signed key (Col. 8 lines 45-67; access is granted and established connection based on signed token)), (Col. 2 lines 38-50; client signed key (signing of access token))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith and Antonas to incorporate the teaching of Cannata to utilize the above feature because of the analogous concept of application and mapping to a microservice containerized environment using cloud computing, with the motivation of implementing a process in which microservice containers evaluate access and use proxy servers and policy management to validate access request prevent bottlenecking and promote high responsiveness and authentication for high impact and performance. (Cannata Col. 1 lines 15-37 and 45-67))
In regards to Claim 18, the combination of Amaro, Smith, Antonas and Cannata teach the non-transitory computer-readable storage medium of claim 16, Smith further teaches wherein the sidecar is protected by a confidential compute architecture. (Par. (0132); microservice and sidecar with trusted domain of trusted execution environment. For instance, in par. (0133), there may be a local secure path between the microservice and sidecar based on local cryptographic keys (e.g., established with a DICE architecture) where the microservice is provisioned with a policy that allows it to attest and trust the sidecar. The side-car also may be provisioned with a policy that allows it to attest and trust the microservice. Also, it will be understood that the microservice and sidecar may be bound or securely associated in other ways, whether using a hypervisor, microcode, or other features to establish a trusted binding/path between the microservice and sidecar.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Antonas and Cannata to incorporate the teaching of Smith to utilize the above feature because of the analogous concept of microservice containers and authentication techniques in cloud computing, with the motivation of improving compliance and security in cloud-like distribution services to create trust and end-to-end security protection. (Smith Par. (0003-0006))
Claim(s) 2, 11 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amaro et al. (U.S Pub. No. 20220405116 (see U.S provisional application 63/211,535), hereinafter referred to as “Amaro”), Smith et al. (U.S Pub. No. 20200127980, hereinafter referred to as “Smith”), Antonas et al. (U.S Pub. No. 20220006862, hereinafter referred to as “Antonas”) and Cannata et al. (U.S No. 11431513, hereinafter referred to as “Cannata”) further in view of Clerget et al. (U.S No. 11055428, hereinafter referred to as “Clerget”)
In regards to Claim 2, the combination of Amaro, Smith, Antonas and Cannata do not explicitly teach wherein the microservice container to deploy is identified in an application manifest provided to the CPEF edge component from a remote CPEF controller.
Wherein Clerget teaches wherein the microservice container to deploy is identified in an application manifest provided to the CPEF edge component from a remote CPEF controller. (Col. 7 lines 30-45; container prior to being deployed has a controller that obtains a container manifest that is transferred from a remote node))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith, Antonas and Cannata to incorporate the teaching of Clerget to utilize the above feature because of the analogous concept of application and mapping to a deploying in containerized environment using cloud computing, with the motivation of preventing compromise with data transmitted over the network at different stages with multiple nodes. By deploying containers to run as well as deployment at remote controllers, data can be protected from risk and alteration. (Clerget Col. 5-22)
In regards to Claim 11, the combination of Amaro, Smith, Antonas and Cannata do not explicitly teach wherein the microservice container to deploy is identified in an application manifest provided to the CPEF edge component from a remote CPEF controller.
Wherein Clerget teaches wherein the microservice container to deploy is identified in an application manifest provided to the CPEF edge component from a remote CPEF controller. (Col. 7 lines 30-45; container prior to being deployed has a controller that obtains a container manifest that is transferred from a remote node))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith, Antonas and Cannata to incorporate the teaching of Clerget to utilize the above feature because of the analogous concept of application and mapping to a deploying in containerized environment using cloud computing, with the motivation of preventing compromise with data transmitted over the network at different stages with multiple nodes. By deploying containers to run as well as deployment at remote controllers, data can be protected from risk and alteration. (Clerget Col. 5-22)
In regards to Claim 17, the combination of Amaro, Smith, Antonas and Cannata do not explicitly teach wherein the microservice container to deploy is identified in an application manifest provided to the CPEF edge component from a remote CPEF controller.
Wherein Clerget teaches wherein the microservice container to deploy is identified in an application manifest provided to the CPEF edge component from a remote CPEF controller. (Col. 7 lines 30-45; container prior to being deployed has a controller that obtains a container manifest that is transferred from a remote node))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith, Antonas and Cannata to incorporate the teaching of Clerget to utilize the above feature because of the analogous concept of application and mapping to a deploying in containerized environment using cloud computing, with the motivation of preventing compromise with data transmitted over the network at different stages with multiple nodes. By deploying containers to run as well as deployment at remote controllers, data can be protected from risk and alteration. (Clerget Col. 5-22)
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amaro et al. (U.S Pub. No. 20220405116 (see U.S provisional application 63/211,535), hereinafter referred to as “Amaro”), Smith et al. (U.S Pub. No. 20200127980, hereinafter referred to as “Smith”), Antonas et al. (U.S Pub. No. 20220006862, hereinafter referred to as “Antonas”), and Cannata et al. (U.S No. 11431513, hereinafter referred to as “Cannata”) further in view of Ned Smith et al. (U.S Pub. No. 20210012282, hereinafter referred to as “Ned Smith”)
In regards to Claim 4, the combination of Amaro, Smith, Antonas and Cannata teach the apparatus of claim 1, Smith further teaches wherein the sidecar is implemented in a trust domain (TD) of the TDX confidential compute architecture. (Par. (0132); microservice and sidecar with trusted domain of trusted execution environment. For instance, as disclosed in par. (0133), there may be a local secure path between the microservice and sidecar based on local cryptographic keys (e.g., established with a DICE architecture) where the microservice is provisioned with a policy that allows it to attest and trust the sidecar. The side-car also may be provisioned with a policy that allows it to attest and trust the microservice. Also, it will be understood that the microservice and sidecar may be bound or securely associated in other ways, whether using a hypervisor, microcode, or other features to establish a trusted binding/path between the microservice and sidecar.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Antonas and Cannata to incorporate the teaching of Smith to utilize the above feature because of the analogous concept of microservice containers and authentication techniques in cloud computing, with the motivation of improving compliance and security in cloud-like distribution services to create trust and end-to-end security protection. (Smith Par. (0003-0006))
Amaro, Smith, Antonas and Cannata do not explicitly teach wherein the confidential compute architecture comprises an Intel@ Trusted Domain eXtensions® (TDX) confidential compute architecture, and wherein the sidecar is implemented in a trust domain (TD) of the TDX confidential compute architecture.
Wherein Ned Smith teaches wherein the confidential compute architecture comprises an Intel@ Trusted Domain eXtensions® (TDX) confidential compute architecture, and ((Par. (0131 and 0133); sidecar (proxy) is protected by confidential compute architecture (TDX of encryptor 908 associated with proxy)), (Figure 9 labels 908 and 912; sidecar (proxy) is protected by confidential compute architecture (TDX of label 908))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith, Antonas and Cannata to incorporate the teaching of Ned Smith to utilize the above feature because of the analogous concept of cloud computing using sidecar/proxies in trusted environment, with the motivation of creating trustworthiness of hardware devices and creating an attestation process that allows edge devices in cloud computing to execute access and share data. (Ned Smith Par. (0051))
Claim(s) 6, 14 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amaro et al. (U.S Pub. No. 20220405116 (see U.S provisional application 63/211,535), hereinafter referred to as “Amaro”), Smith et al. (U.S Pub. No. 20200127980, hereinafter referred to as “Smith”) Antonas et al. (U.S Pub. No. 20220006862, hereinafter referred to as “Antonas”) and Cannata et al. (U.S No. 11431513, hereinafter referred to as “Cannata”) further in view of Biernat et al. (U.S Pub. No. 20220091583, hereinafter referred to as “Biernat”)
In regards to Claim 6, the combination of Amaro, Smith, Antonas and Cannata teach the apparatus of claim 1, Cannata further teaches client signed key (Col. 6 lines 5-45 and Col. 6 lines 60-6; sidecar (gateway node) generates signed client key (generates signed access token from user)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith and Antonas to incorporate the teaching of Cannata to utilize the above feature because of the analogous concept of application and mapping to a microservice containerized environment using cloud computing, with the motivation of using the client signed key to enhance authentication and allow microservices and containers to identify rightful and authorized access based on the signed key. (Cannata Col. 6 lines 60-67 and Col. 7 lines 1-25))
Amaro, Smith, Antonas and Cannata do not explicitly teach wherein the sidecar is to at least one of rotate or renew the …key for the microservice container.
Wherein Biernat teaches wherein the sidecar is to at least one of rotate or renew the …key for the microservice container. (Par. (0038-0039); sidecar (proxy node) renew the key (key refreshes)), (Par. (0072); key for the microservice container (container with microservice associated with packages and pushing firmware updates etc. with encryption keys)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith, Antonas, and Cannata to incorporate the teaching of Biernat to utilize the above feature because of the analogous concept of microservices in containerized environment using key exchanges, with the motivation of implementing a key refresh interaction with containers can be more secure and activities within the system can be effectively performed as well as having a system of checks conducted by the proxy. (Biernat Par. (0032, 0039 and 0075))
In regards to Claim 14, the combination of Amaro, Smith, Antonas and Cannata teach the method of claim 10, Cannata further teaches client signed key (Col. 6 lines 5-45 and Col. 6 lines 60-6; sidecar (gateway node) generates signed client key (generates signed access token from user)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith and Antonas to incorporate the teaching of Cannata to utilize the above feature because of the analogous concept of application and mapping to a microservice containerized environment using cloud computing, with the motivation of using the client signed key to enhance authentication and allow microservices and containers to identify rightful and authorized access based on the signed key (Cannata Col. 6 lines 60-67 and Col. 7 lines 1-25))
Amaro, Smith, Antonas and Cannata do not explicitly teach wherein the sidecar is to at least one of rotate or renew the …key for the microservice container.
Wherein Biernat teaches wherein the sidecar is to at least one of rotate or renew the …key for the microservice container. (Par. (0038-0039); sidecar (proxy node) renew the key (key refreshes)), (Par. (0072); key for the microservice container (container with microservice associated with packages and pushing firmware updates etc. with encryption keys)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith, Antonas, and Cannata to incorporate the teaching of Biernat to utilize the above feature because of the analogous concept of microservices in containerized environment using key exchanges, with the motivation of implementing a key refresh interaction with containers can be more secure and activities within the system can be effectively performed as well as having a system of checks conducted by the proxy. (Biernat Par. (0032, 0039 and 0075))
In regards to Claim 19, the combination of Amaro, Smith, Antonas and Cannata teach non-transitory computer-readable storage medium of claim 16, Cannata further teaches client signed key (Col. 6 lines 5-45 and Col. 6 lines 60-6; sidecar (gateway node) generates signed client key (generates signed access token from user)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith and Antonas to incorporate the teaching of Cannata to utilize the above feature because of the analogous concept of application and mapping to a microservice containerized environment using cloud computing, with the motivation of using the client signed key to enhance authentication and allow microservices and containers to identify rightful and authorized access based on the signed key. (Cannata Col. 6 lines 60-67 and Col. 7 lines 1-25))
Amaro, Smith, Antonas and Cannata do not explicitly teach wherein the sidecar is to at least one of rotate or renew the …key for the microservice container.
Wherein Biernat teaches wherein the sidecar is to at least one of rotate or renew the …key for the microservice container. (Par. (0038-0039); sidecar (proxy node) renew the key (key refreshes)), (Par. (0072); key for the microservice container (container with microservice associated with packages and pushing firmware updates etc. with encryption keys)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith, Antonas, and Cannata to incorporate the teaching of Biernat to utilize the above feature because of the analogous concept of microservices in containerized environment using key exchanges, with the motivation of implementing a key refresh interaction with containers can be more secure and activities within the system can be effectively performed as well as having a system of checks conducted by the proxy. (Biernat Par. (0032, 0039 and 0075))
Claim(s) 7-8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amaro et al. (U.S Pub. No. 20220405116 (see U.S provisional application 63/211,535), hereinafter referred to as “Amaro”), Smith et al. (U.S Pub. No. 20200127980, hereinafter referred to as “Smith”) Antonas et al. (U.S Pub. No. 20220006862, hereinafter referred to as “Antonas”), and Cannata et al. (U.S No. 11431513, hereinafter referred to as “Cannata”) further in view of Adam et al. (U.S Pub. No. 20230155984, hereinafter referred to as “Adam”)
In regards to Claim 7, the combination of Amaro, Smith, Antonas and Cannata do not explicitly teach wherein the sidecar is part of a service mesh of the application.
Wherein Adam teaches wherein the sidecar is part of a service mesh of the application. (Par. (0037); service mesh with application and proxy/sidecar with containers))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith, Antonas, and Cannata to incorporate the teaching of Adam to utilize the above feature because of the analogous concept of a containerized environment in a cloud system, with the motivation of creating a dynamic sharing environment while preventing security risks and using service meshes to produce a hierarchy of organizational structures, administrators etc. and be able to mitigate malicious insiders and create trust within the security model to not misconfigure access within the mesh network as well as enhance the security services of containers. (Adam Par. (0004-0005 and 0008-0009))
In regards to Claim 8, the combination of Amaro, Smith, Antonas and Cannata do not explicitly teach wherein the secure communication channel is established using at least one a Quick UDP Internet Connections (QUIC) protocol or a transport layer security (TLS) protocol.
Wherein Adam teaches wherein the secure communication channel is established using at least one a Quick UDP Internet Connections (QUIC) protocol or a transport layer security (TLS) protocol. (Par. (0045); container and sidecar proxy corresponding to TLS with secure communication and channel that is encrypted)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith, Antonas, and Cannata to incorporate the teaching of Adam to utilize the above feature because of the analogous concept of a containerized environment in a cloud system, with the motivation of creating a secure channel that is encrypted to prevent compromise based on mutually authenticated parties through the TLS protocol. (Adam Par. (0045-0047))
Claim(s) 9, 15 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Amaro et al. (U.S Pub. No. 20220405116 (see U.S provisional application 63/211,535), hereinafter referred to as “Amaro”), Smith et al. (U.S Pub. No. 20200127980, hereinafter referred to as “Smith”) Antonas et al. (U.S Pub. No. 20220006862, hereinafter referred to as “Antonas”) and Cannata et al. (U.S No. 11431513, hereinafter referred to as “Cannata”) further in view of Tobias et al. (U.S Pub. No. 20190205317, hereinafter referred to as “Tobias”)
In regards to Claim 9, the combination of Amaro, Smith, Antonas and Cannata teach the apparatus of claim 1, Cannata further teaches client signed key (Col. 6 lines 5-45 and Col. 6 lines 60-67; sidecar (gateway node) generates signed client key (generates signed access token from user)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith and Antonas to incorporate the teaching of Cannata to utilize the above feature because of the analogous concept of application and mapping to a microservice containerized environment using cloud computing, with the motivation of using the client signed key to enhance authentication and allow microservices and containers to identify rightful and authorized access based on the signed key. (Cannata Col. 6 lines 60-67 and Col. 7 lines 1-25))
Amaro, Smith, Antonas and Cannata do not explicitly teach wherein the ….key is provided by a server hosting the application and is obtained from an application manifest provided by a remote CPEF controller, and wherein the server utilizes remote attestation to verify the …key.
Wherein Tobias teaches wherein the ….key is provided by a server hosting the application and is obtained from an application manifest provided by a remote CPEF controller, and (Par. (0075-0077); provided by a server hosting (server sends key to each client with encrypted manifest) and is obtained from an application manifest provided by a remote (user device that is remote obtains key and manifest)), (Par. (0116); an application manifest provided by a remote CPEF controller (user/client devices corresponding to remote device)), (Figure 17E labels 1724, 1728 and Par. (0156); an application manifest provided by a remote CPEF controller (user with interface application corresponding to remote device with an application manifest and container))
wherein the server utilizes remote attestation to verify the …key. (Par. (0130); remote key server and authenticating of corresponding keys))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith, Antonas, and Cannata to incorporate the teaching of Tobias to utilize the above feature because of the analogous concept of a containerized environment in a cloud system, with the motivation of creating a security solutions to be able to store and retrieve data and implementing a secure storage system before fragments are transmitted to establish a secure channel and utilize keys to multiple destinations and provide a performance advantage. (Tobias Par. (0008-0009 and 0058 and 0074-0076))
In regards to Claim 15, the combination of Amaro, Smith, Antonas and Cannata teach the method of claim 10, Cannata further teaches client signed key (Col. 6 lines 5-45 and Col. 6 lines 60-67; sidecar (gateway node) generates signed client key (generates signed access token from user)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith and Antonas to incorporate the teaching of Cannata to utilize the above feature because of the analogous concept of application and mapping to a microservice containerized environment using cloud computing, with the motivation of using the client signed key to enhance authentication and allow microservices and containers to identify rightful and authorized access based on the signed key. (Cannata Col. 6 lines 60-67 and Col. 7 lines 1-25))
Amaro, Smith, Antonas and Cannata do not explicitly teach wherein the ….key is provided by a server hosting the application and is obtained from an application manifest provided by a remote CPEF controller, and wherein the server utilizes remote attestation to verify the …key.
Wherein Tobias teaches wherein the ….key is provided by a server hosting the application and is obtained from an application manifest provided by a remote CPEF controller, and (Par. (0075-0077); provided by a server hosting (server sends key to each client with encrypted manifest) and is obtained from an application manifest provided by a remote (user device that is remote obtains key and manifest)), (Par. (0116); an application manifest provided by a remote CPEF controller (user/client devices corresponding to remote device)), (Figure 17E labels 1724, 1728 and Par. (0156); an application manifest provided by a remote CPEF controller (user with interface application corresponding to remote device with an application manifest and container))
wherein the server utilizes remote attestation to verify the …key. (Par. (0130); remote key server and authenticating of corresponding keys))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith, Antonas, and Cannata to incorporate the teaching of Tobias to utilize the above feature because of the analogous concept of a containerized environment in a cloud system, with the motivation of creating a security solutions to be able to store and retrieve data and implementing a secure storage system before fragments are transmitted to establish a secure channel and utilize keys to multiple destinations and provide a performance advantage. (Tobias Par. (0008-0009 and 0058 and 0074-0076))
In regards to Claim 20, the combination of Amaro, Smith, Antonas and Cannata teach the non-transitory computer-readable storage medium of claim 16, Cannata further teaches client signed key (Col. 6 lines 5-45 and Col. 6 lines 60-67; sidecar (gateway node) generates signed client key (generates signed access token from user)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith and Antonas to incorporate the teaching of Cannata to utilize the above feature because of the analogous concept of application and mapping to a microservice containerized environment using cloud computing, with the motivation of using the client signed key to enhance authentication and allow microservices and containers to identify rightful and authorized access based on the signed key. (Cannata Col. 6 lines 60-67 and Col. 7 lines 1-25))
Amaro, Smith, Antonas and Cannata do not explicitly teach wherein the ….key is provided by a server hosting the application and is obtained from an application manifest provided by a remote CPEF controller, and wherein the server utilizes remote attestation to verify the …key.
Wherein Tobias teaches wherein the ….key is provided by a server hosting the application and is obtained from an application manifest provided by a remote CPEF controller, and (Par. (0075-0077); provided by a server hosting (server sends key to each client with encrypted manifest) and is obtained from an application manifest provided by a remote (user device that is remote obtains key and manifest)), (Par. (0116); an application manifest provided by a remote CPEF controller (user/client devices corresponding to remote device)), (Figure 17E labels 1724, 1728 and Par. (0156); an application manifest provided by a remote CPEF controller (user with interface application corresponding to remote device with an application manifest and container))
wherein the server utilizes remote attestation to verify the …key. (Par. (0130); remote key server and authenticating of corresponding keys))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Amaro, Smith, Antonas, and Cannata to incorporate the teaching of Tobias to utilize the above feature because of the analogous concept of a containerized environment in a cloud system, with the motivation of creating a security solutions to be able to store and retrieve data and implementing a secure storage system before fragments are transmitted to establish a secure channel and utilize keys to multiple destinations and provide a performance advantage. (Tobias Par. (0008-0009 and 0058 and 0074-0076))
Relevant Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Li; Xiaoning (U.S Pub. No. 20200220713) “SECURE COMMUNICATION WITH A TRUSTED EXECUTION ENVIRONMENT”. Considered this reference because it containers and trusted environment for key exchanges in cloud system.
Wang; Yue. (U.S Pub. No. 20210240540) “SERVERLESS PLATFORM REQUEST ROUTING”. Considered this application because it relates containerized environment and microservices.
ERIKSSON; Magnus (U.S Pub. No. 20210258300) “METHOD FOR RE-PROVISIONING A DIGITAL SECURITY CERTIFICATE AND A SYSTEM AND A NON-TRANSITORY COMPUTER PROGRAM PRODUCT THEREOF”. Considered this application because it addressed controller and root keys in TLS protocol environment with key distribution.
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 HASSAN A HUSSEIN whose telephone number is (571)272-3554. The examiner can normally be reached on 7:30am-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, Eleni Shiferaw can be reached on (571)272-3867. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-y.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/H.A.H./Examiner, Art Unit 2497
/ALI H. CHEEMA/Primary Examiner, Art Unit 2497
Prosecution Insights