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 .
DETAILED ACTION
This office action is in response to the application filed on 10/10/2024. In which, claims 1-20 are pending and being considered, claims 1, 10 and 16 are independent, claims 1-20 are rejected.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 10/10/2024 and 01/29/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Specification
Applicant is reminded of the proper language and format for an abstract of the disclosure.
The abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length. The abstract should describe the disclosure sufficiently to assist readers in deciding whether there is a need for consulting the full patent text for details.
The language should be clear and concise and should not repeat information given in the title. It should avoid using phrases which can be implied, such as, “The disclosure concerns,” “The disclosure defined by this invention,” “The disclosure describes,” etc. In addition, the form and legal phraseology often used in patent claims, such as “means” and “said,” should be avoided.
The disclosure is objected to because of the following informalities: the abstract on line 1 states “disclosure”. Appropriate correction is required.
The disclosure is objected to because it contains an embedded hyperlink and/or other form of browser-executable code “http://aaa.com” is stated on Par. (0018), (0046) and (0059) of the specification. Applicant is required to delete the embedded hyperlink and/or other form of browser-executable code; references to websites should be limited to the top-level domain name without any prefix such as http:// or other browser-executable code. See MPEP § 608.01.
The use of the term “Wi-Fi” is stated on Par. (0034) of the specification, which is a trade name or a mark used in commerce, has been noted in this application. The term should be accompanied by the generic terminology; furthermore the term should be capitalized wherever it appears or, where appropriate, include a proper symbol indicating use in commerce such as ™, SM , or ® following the term.
Although the use of trade names and marks used in commerce (i.e., trademarks, service marks, certification marks, and collective marks) are permissible in patent applications, the proprietary nature of the marks should be respected and every effort made to prevent their use in any manner which might adversely affect their validity as commercial marks.
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Objections
Claims 6, 8-9, 14-15 and 19-20 is objected to because of the following informalities:
In regards to Claims 6, 9, 14-15 and 19-20, the applicant recites the limitation “client-signed-key”, this is a minor typographically error as independent claims 1, 10 and 16 recite the limitation “client signed key” without the hyphen. Examiner suggest reciting consistent claim language throughout the claims with either ““client-signed-key” or “client signed key” recited. Appropriate correction is required.
In regards to Claim 8, the applicant recites the limitation “QUIC”, this is a typographical error as all abbreviations should be recite fully when first reciting the limitation. QUIC should read “Quick UDP Internet Connections (QUIC)”. Appropriate correction is required.
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, 5, 10, 13 and 16 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”) 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; 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 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 initialize a sidecar for the microservice container; (Par. (0016-0017 and 0068); initializing a sidecar (proxy with redirect) for microservice container (container)), (Par. (0072); microservice container))
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 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 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; (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)(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; 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 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 5, the combination of Amaro, 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 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; generating, by the sidecar, a client signed key using at least one of the root key and a hostname of the microservice; providing, by the sidecar, the client signed key to 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 initializing a sidecar for the microservice container; (Par. (0016-0017 and 0068); initializing a sidecar (proxy with redirect) for microservice container (container ), (Par. (0072); microservice container))
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 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; providing, by the sidecar, the client signed key to 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; (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),(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; 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 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 13, the combination of Amaro, 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 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; generating, by the sidecar, a client signed key using at least one of the root key and a hostname of the microservice; providing, by the sidecar, the client signed key to 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 initializing a sidecar for the microservice container; (Par. (0016-0017 and 0068); initializing a sidecar (proxy with redirect) for microservice container (container ), (Par. (0072); microservice container))
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 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; providing, by the sidecar, the client signed key to 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; (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), (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; 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 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))
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”), 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, 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, 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, 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, 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, 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, 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) 3, 12 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”), 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 Smith et al. (U.S Pub. No. 20210012282, hereinafter referred to as “Smith”)
In regards to Claim 3, the combination of Amaro, Antonas and Cannata do not explicitly teach wherein the sidecar is protected by a confidential compute architecture.
Wherein Smith teaches wherein the sidecar is protected by a confidential compute architecture. (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, Antonas and Cannata to incorporate the teaching of 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. (Smith Par. (0051))
In regards to Claim 12, the combination of Amaro, Antonas and Cannata do not explicitly teach wherein the sidecar is protected by a confidential compute architecture.
Wherein Smith teaches wherein the sidecar is protected by a confidential compute architecture. (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, Antonas and Cannata to incorporate the teaching of 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. (Smith Par. (0051))
In regards to Claim 18, the combination of Amaro, Antonas and Cannata do not explicitly teach wherein the sidecar is protected by a confidential compute architecture.
Wherein Smith teaches wherein the sidecar is protected by a confidential compute architecture. (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, Antonas and Cannata to incorporate the teaching of 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. (Smith Par. (0051))
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”), Antonas et al. (U.S Pub. No. 20220006862, hereinafter referred to as “Antonas”), Cannata et al. (U.S No. 11431513, hereinafter referred to as “Cannata”) and Smith et al. (U.S Pub. No. 20210012282, hereinafter referred to as “Smith”) further in view of Doshi et al. (U.S Pub. No. 20210117249, hereinafter referred to as “Doshi”)
In regards to Claim 4, the combination of Amaro, 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 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, Antonas and Cannata to incorporate the teaching of 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. (Smith Par. (0051))
Amaro, Antonas and Cannata and Smith do not explicitly teach wherein the sidecar is implemented in a trust domain (TD) of the TDX confidential compute architecture.
Wherein Doshi teaches wherein the sidecar is implemented in a trust domain (TD) of the TDX confidential compute architecture. (Par. (0210, 0212 and 0216) sidecar agents/proxy corresponding to TDX and trust domain))
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, Cannata and Smith to incorporate the teaching of Doshi to utilize the above feature because of the analogous concept of cloud computing using sidecar/proxies in trusted environment, with the motivation of creating a root of trust for edge devices in cloud network to regulate access and improve security of hardware functions as the services changes with users and fluctuates. (Doshi Par. (0102))
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”), 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, 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 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, 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, 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, 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 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, 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, 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, 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 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, 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, 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”), 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, 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, 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, Antonas and Cannata do not explicitly teach wherein the secure communication channel is established using at least one a QUIC protocol or a transport layer security (TLS) protocol.
Wherein Adam teaches wherein the secure communication channel is established using at least one a 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, 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”), 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, 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 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, 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, 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, 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 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, 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, 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, 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 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, 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, 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
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-my.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.
/HASSAN A HUSSEIN/ Examiner, Art Unit 2497