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 .
This Office Action is in response to the Amendment filed on 01/13/2026.
In the instant Amendment, claim 5 was cancelled; claims 1, 13, 16, and 20 have been amended; and claims 1, 13, and 20 are independent claims. Claims 1-4 and 6-20 have been examined and are pending. This Action is made FINAL.
Response to Arguments
Applicants’ arguments in the instant Amendment, filed on 01/13/2026, with respect to limitations listed below, have been fully considered but they are not persuasive.
Applicant’s arguments: “[N]either Inman nor Saye discloses obtaining metadata that includes a list of external resource endpoints to be whitelisted, the metadata being obtained by a watcher of an edge proxy in each layer, via a data plane service," as claimed.”
The Examiner disagrees with the Applicants. The Examiner respectfully submits that Inman discloses obtaining metadata that includes a list of external resource endpoints to be whitelisted, the metadata being obtained by a watcher of an edge proxy in each layer, via a data plane (Inman: par. 0048 the one or more identifiers of the access request message includes a MAC address, and the apparatus compares the received MAC address to a list of known MAC addresses with corresponding known hierarchical penetration levels associated with the known MAC addresses. Alternatively, the one or more identifiers of the access request message includes a manufacturing serial number of the computing device 112 or any other piece of data that uniquely identifies the computing device; par. 0049 the multi-layer network 300B, including the switch 102, is configured to grant the computing device access and control privileges for the multi-layer network, the access and control privileges permitting access up to a permitted level of the hierarchical levels of the multi-layer network that corresponds to the hierarchical penetration level assigned to the computing device). More specifically, Inman discloses assigning, by the apparatus, the second hierarchical penetration level to the computing device, and thereby permitting the computing device access to an isolated network access and control zone isolated from the rest of the multi-layer network except for other devices in the isolated network access and control zone; and permitting the computing device to communicate with other computing devices within the isolated network access and control zone which have also been assigned to the second hierarchical penetration level [par. 0012] and the security system includes an apparatus 202A for controlling access of a computing device, such as the computing device from FIG. 1, to a multi-layer network implementing a zero-trust architecture. The security system, which is implemented in any suitable network such as the network in FIG. 1, further comprises a switch for controlling access to a plurality of hierarchical levels of the multi-layer network [par. 0042]. Therefore, the examiner finds this argument not persuasive.
Applicant’s arguments with respect to amended limitations of claims 1, 13, and 20 have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection. The new reference Wang et al. (US 2012/0272058) used to address the limitations.
The amended claims 1, 13 and 20 have been addressed in rejection below.
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 of this title, 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 6-10, 13, 17-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Inman, II et al. (“Inman,” US 2024/0064180) in view of NPL Deep Dive: Creating hierarchies of Azure IoT Edge devices (ISA-95) – Parts 1-3 (“Saye,”) and Wang et al. (“Wang,” US 2012/0272058).
Regarding claim 1: Inman discloses a computer implemented method comprising:
generating a call to an external endpoint from a resource in a first layer of a multi-layer air-gapped network of resources (Inman: par. 0047 the apparatus to receive an access request message from a computing device (e.g., the first computing device 312, second computing device 313, or any other wired or wireless computing device in communication with the switch), the access request message including one or more identifiers associated with the computing device for requesting access to the multi-layer network 300B; par. 0050 permit the computing device access and control privileges to an isolated network access and control zone 320 separate from and non-communicative with the rest of the multi-layer network 321); and
obtaining metadata that includes a list of external resource endpoints to be whitelisted (Inman: par. 0048 the one or more identifiers of the access request message includes a MAC address, and the apparatus compares the received MAC address to a list of known MAC addresses with corresponding known hierarchical penetration levels associated with the known MAC addresses. Alternatively, the one or more identifiers of the access request message includes a manufacturing serial number of the computing device 112 or any other piece of data that uniquely identifies the computing device), the metadata being obtained by a watcher of an edge proxy in each layer, via a data plane service (Inman: par. 0049 the multi-layer network 300B, including the switch 102, is configured to grant the computing device access and control privileges for the multi-layer network, the access and control privileges permitting access up to a permitted level of the hierarchical levels of the multi-layer network that corresponds to the hierarchical penetration level assigned to the computing device).
Inman does not explicitly disclose generating, via each edge proxy, a dummy certificate for the external endpoints to create trust between edge proxies at adjacent layers in the air- gapped network and forwarding the call from a call forwarder in each layer to the edge proxy in each adjacent layer to a top layer having network access to the external endpoint.
However, Saye discloses generating, via each edge proxy, a dummy certificate for the external endpoints to create trust between edge proxies at adjacent layers in the air- gapped network (Saye: page 3 (3/13) each layer will need to resolve the name of the parent layer. Because of container networking, this should be the fully qualified name resolvable via DNS [] and the name will need to match the x509 certificate [] because the child layer connects to the parent layer via an encrypted communication, x509 certificates are involved [] each layer should have a unique fully qualified name, and this name should be in the certificate; page 24 (11of 21) create certificate chain (aka bundle) files); and
forwarding the call from a call forwarder in each layer to the edge proxy in each adjacent layer to a top layer having network access to the external endpoint (Saye: page 2 (2/13)Azure IoT edge at each layer for communicating through hierarchy, forming a transaction control protocol (TCP) tunnel between the first resource and the external resource (TCP protocol for layer communication; page 5 (5/13) once the host OS trust the Certificate authority, we next have edgeHub on the child layer that will start and attempt to communicate with the edgeHub on the parent layer [layer 4 configuration with TCP connection creation for azureiotedge-hub, multi-layer communications from level 2 (L2) -> level 3 (L3) -> level 4 (L4) -> firewall -> Azure Cloud, where communications from L3 or L2 go through the hierarchy of Levels and accompanying Azure loT Edges to communicate to the internet. The Azure loT Edges, which show an edge proxy at each level (when the loT Edge receives a call from a lower level) and a call forwarder (since communications are passed through, i.e. forwarded, to each Azure loT Edge successively)]).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Saye with the system/method of Inman to include generating, via each edge proxy, a dummy certificate for the external endpoints to create trust between edge proxies at adjacent layers in the air- gapped network. One would have been motivated to use firewalls in-between each layer preventing layers from communicating directly to the internet, forcing them to go through the hierarchy by using a private Certificate Authority and will use Preshared Keys for all levels to authenticate to IoT Hub (Saye: page 15 (2 of 21)).
Inman in view of Saye does not explicitly disclose a dummy certificate that is self-signed and automatically generated by a secret discover service (SDS) subservice of the edge proxy acting as said watcher for each external endpoint identified in the list.
However, Wang discloses a dummy certificate that is self-signed and automatically generated by a secret discover service (SDS) subservice of the edge proxy acting as said watcher for each external endpoint identified in the list (Wang: par. 0035 the proxy device 120 may generate a dynamic (client) certificate by signing the client's subject name ("client") using the proxy device's private key; par. 0037 the proxy device 120 (e.g., proxy services 244) thus transparently proxies the connection between the client/server endpoints of a client-server security session; par. 0014 the server may be a call controller, and the proxy device may be a firewall; par. 0019 server services 244 also provides for the signaling (control) and transmission of VoIP traffic, such as where the server 110 is a call controller to interact with the client IP phones).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Wang with the system/method of Inman and Saye to include a dummy certificate that is self-signed and automatically generated by a secret discover service (SDS) subservice of the edge proxy. One would have been motivated to create a dynamic certificate using the obtained client security information and the trusted proxy certificate by the proxy device, and establishes the initiated proxy-server security session with the dynamic certificate (Wang: par. 0013).
Regarding claim 6: Inman in view of Saye and Wang discloses the method of claim 1.
Saye further discloses wherein the metadata is provided to the edge proxies based on an established parent-child relationships between edge proxies in adjacent layers (Saye: page 9 (9/13) once edgeAgent is running and the deployment has been received, it will start pulling and starting he system and custom modules [] where the child layer is pointed to the parent layer to pull the images. If we look at the images on the child layer, we now see they are all pulled from the parent layer).
The motivation is the same that of claim 1 above.
Regarding claim 7: Inman in view of Saye and Wang discloses the method of claim 1.
Saye further discloses wherein the data plane service is part of a cloud service that manages resources in the layers of the multi-layer air-gapped network (Saye: page 37 (3/16) the figure shows the cloud components in using Azure private link and private endpoints to secure Azure IoT traffic).
The motivation is the same that of claim 1 above.
Regarding claim 8: Inman in view of Saye and Wang discloses the method of claim 1.
Saye further discloses wherein the air-gapped network comprises a multi-layer network of clusters of resources wherein data passes only through adjacent layers (Saye: page 1 (1/13) 2nd paragraph where layer 2 may only communicate to layer 3, 3 to 4 and 4 to the internet).
The motivation is the same that of claim 1 above.
Regarding claim 9: Inman in view of Saye and Wang discloses the method of claim 1.
Saye further discloses wherein the air-gapped network comprises an ISA/95 compliant network (Saye: page 1 (1/13) 1st paragraph Creating hierarchies of Azure IoT Edge devices (ISA-95)).
The motivation is the same that of claim 1 above.
Regarding claim 10: Inman in view of Saye and Wang discloses the method of claim 1.
Saye further discloses wherein the call is for an extension that comprises an application or new device to add to the air-gapped network (Saye: page 1 (1/13) overview of a nested edge typology: to add additional security, we can also include an isolated network from Layer 4 to the Cloud).
The motivation is the same that of claim 1 above.
Regarding claim 13: Inman discloses a machine-readable storage device having instructions for execution by a processor of a machine to cause the processor to perform operations to perform a method, the operations comprising:
generating a call to an external endpoint from a resource in a first layer of a multi-layer air-gapped network of resources (Inman: par. 0047 the apparatus to receive an access request message from a computing device (e.g., the first computing device 312, second computing device 313, or any other wired or wireless computing device in communication with the switch), the access request message including one or more identifiers associated with the computing device for requesting access to the multi-layer network 300B; par. 0050 permit the computing device access and control privileges to an isolated network access and control zone 320 separate from and non-communicative with the rest of the multi-layer network 321); and
obtaining metadata that includes a list of external resource endpoints to be whitelisted (Inman: par. 0048 the one or more identifiers of the access request message includes a MAC address, and the apparatus compares the received MAC address to a list of known MAC addresses with corresponding known hierarchical penetration levels associated with the known MAC addresses. Alternatively, the one or more identifiers of the access request message includes a manufacturing serial number of the computing device 112 or any other piece of data that uniquely identifies the computing device), the metadata being obtained by a watcher of an edge proxy in each layer, via a data plane service (Inman: par. 0049 the multi-layer network 300B, including the switch 102, is configured to grant the computing device access and control privileges for the multi-layer network, the access and control privileges permitting access up to a permitted level of the hierarchical levels of the multi-layer network that corresponds to the hierarchical penetration level assigned to the computing device).
Inman does not explicitly disclose generating, via each edge proxy, a dummy certificate for the external endpoints to create trust between edge proxies at adjacent layers in the air- gapped network and forwarding the call from a call forwarder in each layer to the edge proxy in each adjacent layer to a top layer having network access to the external endpoint.
However, Saye discloses generating, via each edge proxy, a dummy certificate for the external endpoints to create trust between edge proxies at adjacent layers in the air- gapped network (Saye: page 3 (3/13) each layer will need to resolve the name of the parent layer. Because of container networking, this should be the fully qualified name resolvable via DNS [] and the name will need to match the x509 certificate [] because the child layer connects to the parent layer via an encrypted communication, x509 certificates are involved [] each layer should have a unique fully qualified name, and this name should be in the certificate; page 24 (11of 21) create certificate chain (aka bundle) files); and
forwarding the call from a call forwarder in each layer to the edge proxy in each adjacent layer to a top layer having network access to the external endpoint (Saye: page 2 (2/13)Azure IoT edge at each layer for communicating through hierarchy, forming a transaction control protocol (TCP) tunnel between the first resource and the external resource (TCP protocol for layer communication; page 5 (5/13) once the host OS trust the Certificate authority, we next have edgeHub on the child layer that will start and attempt to communicate with the edgeHub on the parent layer [layer 4 configuration with TCP connection creation for azureiotedge-hub, multi-layer communications from level 2 (L2) -> level 3 (L3) -> level 4 (L4) -> firewall -> Azure Cloud, where communications from L3 or L2 go through the hierarchy of Levels and accompanying Azure loT Edges to communicate to the internet. The Azure loT Edges, which show an edge proxy at each level (when the loT Edge receives a call from a lower level) and a call forwarder (since communications are passed through, i.e. forwarded, to each Azure loT Edge successively)]).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Saye with the system/method of Inman to include generating, via each edge proxy, a dummy certificate for the external endpoints to create trust between edge proxies at adjacent layers in the air- gapped network. One would have been motivated to use firewalls in-between each layer preventing layers from communicating directly to the internet, forcing them to go through the hierarchy by using a private Certificate Authority and will use Preshared Keys for all levels to authenticate to IoT Hub (Saye: page 15 (2 of 21)).
Inman in view of Saye does not explicitly disclose a dummy certificate that is self-signed and automatically generated by a secret discover service (SDS) subservice of the edge proxy acting as said watcher for each external endpoint identified in the list.
However, Wang discloses a dummy certificate that is self-signed and automatically generated by a secret discover service (SDS) subservice of the edge proxy acting as said watcher for each external endpoint identified in the list (Wang: par. 0035 the proxy device 120 may generate a dynamic (client) certificate by signing the client's subject name ("client") using the proxy device's private key; par. 0037 the proxy device 120 (e.g., proxy services 244) thus transparently proxies the connection between the client/server endpoints of a client-server security session; par. 0014 the server may be a call controller, and the proxy device may be a firewall; par. 0019 server services 244 also provides for the signaling (control) and transmission of VoIP traffic, such as where the server 110 is a call controller to interact with the client IP phones).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Wang with the system/method of Inman and Saye to include a dummy certificate that is self-signed and automatically generated by a secret discover service (SDS) subservice of the edge proxy. One would have been motivated to create a dynamic certificate using the obtained client security information and the trusted proxy certificate by the proxy device, and establishes the initiated proxy-server security session with the dynamic certificate (Wang: par. 0013).
Regarding claim 17: Claim 17 is similar in scope to claim 7, and is therefore rejected under similar rationale.
Regarding claim 18: Inman in view of Saye and Wang discloses the device of claim 1.
Saye further discloses wherein the air-gapped network comprises a multi- layer network of clusters of resources wherein data passes only through adjacent layers (Saye: page 1 (1/13) 2nd paragraph where layer 2 may only communicate to layer 3, 3 to 4 and 4 to the internet) and wherein the call is for an extension that comprises an application or new device to add to the air-gapped network (Saye: page 1 (1/13) overview of a nested edge typology: to add additional security, we can also include an isolated network from Layer 4 to the Cloud).
The motivation is the same that of claim 13 above.
Regarding claim 20: Inman discloses a device comprising:
a processor (Inman: par. 0064 the apparatus includes [] processing circuitry 502 (e.g., processor unit or computer processor)); and
a memory device (Inman: par. 0064 the apparatus includes [] a memory 504 (e.g., storage device)) coupled to the processor and having a program stored thereon for execution by the processor to perform operations comprising:
generating a call to an external endpoint from a resource in a first layer of a multi-layer air-gapped network of resources (Inman: par. 0047 the apparatus to receive an access request message from a computing device (e.g., the first computing device 312, second computing device 313, or any other wired or wireless computing device in communication with the switch), the access request message including one or more identifiers associated with the computing device for requesting access to the multi-layer network 300B; par. 0050 permit the computing device access and control privileges to an isolated network access and control zone 320 separate from and non-communicative with the rest of the multi-layer network 321); and
obtaining metadata that includes a list of external resource endpoints to be whitelisted (Inman: par. 0048 the one or more identifiers of the access request message includes a MAC address, and the apparatus compares the received MAC address to a list of known MAC addresses with corresponding known hierarchical penetration levels associated with the known MAC addresses. Alternatively, the one or more identifiers of the access request message includes a manufacturing serial number of the computing device 112 or any other piece of data that uniquely identifies the computing device), the metadata being obtained by a watcher of an edge proxy in each layer, via a data plane service (Inman: par. 0049 the multi-layer network 300B, including the switch 102, is configured to grant the computing device access and control privileges for the multi-layer network, the access and control privileges permitting access up to a permitted level of the hierarchical levels of the multi-layer network that corresponds to the hierarchical penetration level assigned to the computing device).
Inman does not explicitly disclose generating, via each edge proxy, a dummy certificate for the external endpoints to create trust between edge proxies at adjacent layers in the air- gapped network and forwarding the call from a call forwarder in each layer to the edge proxy in each adjacent layer to a top layer having network access to the external endpoint.
However, Saye discloses generating, via each edge proxy, a dummy certificate for the external endpoints to create trust between edge proxies at adjacent layers in the air- gapped network (Saye: page 3 (3/13) each layer will need to resolve the name of the parent layer. Because of container networking, this should be the fully qualified name resolvable via DNS [] and the name will need to match the x509 certificate [] because the child layer connects to the parent layer via an encrypted communication, x509 certificates are involved [] each layer should have a unique fully qualified name, and this name should be in the certificate; page 24 (11of 21) create certificate chain (aka bundle) files); and
forwarding the call from a call forwarder in each layer to the edge proxy in each adjacent layer to a top layer having network access to the external endpoint (Saye: page 2 (2/13)Azure IoT edge at each layer for communicating through hierarchy, forming a transaction control protocol (TCP) tunnel between the first resource and the external resource (TCP protocol for layer communication; page 5 (5/13) once the host OS trust the Certificate authority, we next have edgeHub on the child layer that will start and attempt to communicate with the edgeHub on the parent layer [layer 4 configuration with TCP connection creation for azureiotedge-hub, multi-layer communications from level 2 (L2) -> level 3 (L3) -> level 4 (L4) -> firewall -> Azure Cloud, where communications from L3 or L2 go through the hierarchy of Levels and accompanying Azure loT Edges to communicate to the internet. The Azure loT Edges, which show an edge proxy at each level (when the loT Edge receives a call from a lower level) and a call forwarder (since communications are passed through, i.e. forwarded, to each Azure loT Edge successively)]).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Saye with the system/method of Inman to include generating, via each edge proxy, a dummy certificate for the external endpoints to create trust between edge proxies at adjacent layers in the air- gapped network. One would have been motivated to use firewalls in-between each layer preventing layers from communicating directly to the internet, forcing them to go through the hierarchy by using a private Certificate Authority and will use Preshared Keys for all levels to authenticate to IoT Hub (Saye: page 15 (2 of 21)).
Inman in view of Saye does not explicitly disclose a dummy certificate that is self-signed and automatically generated by a secret discover service (SDS) subservice of the edge proxy acting as said watcher for each external endpoint identified in the list.
However, Wang discloses a dummy certificate that is self-signed and automatically generated by a secret discover service (SDS) subservice of the edge proxy acting as said watcher for each external endpoint identified in the list (Wang: par. 0035 the proxy device 120 may generate a dynamic (client) certificate by signing the client's subject name ("client") using the proxy device's private key; par. 0037 the proxy device 120 (e.g., proxy services 244) thus transparently proxies the connection between the client/server endpoints of a client-server security session; par. 0014 the server may be a call controller, and the proxy device may be a firewall; par. 0019 server services 244 also provides for the signaling (control) and transmission of VoIP traffic, such as where the server 110 is a call controller to interact with the client IP phones).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Wang with the system/method of Inman and Saye to include a dummy certificate that is self-signed and automatically generated by a secret discover service (SDS) subservice of the edge proxy. One would have been motivated to create a dynamic certificate using the obtained client security information and the trusted proxy certificate by the proxy device, and establishes the initiated proxy-server security session with the dynamic certificate (Wang: par. 0013).
Claims 2-4, 11-12, 14-16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Inman, II et al. (“Inman,” US 2024/0064180) in view of NPL Deep Dive: Creating hierarchies of Azure IoT Edge devices (ISA-95) – Parts 1-3 (“Saye,”), Wang et al. (“Wang,” US 2012/0272058) and Hoffpauir, IV (“Hoffpauir,” US 2023/0224336).
Regarding claim 2: Inman in view of Saye and Wang discloses the method of claim 1.
Inman in view of Saye and Wang does not explicitly disclose decoding traffic from adjacent resources using the dummy certificates via the edge proxy acting as server and client.
However, Hoffpauir discloses decoding traffic from adjacent resources using the dummy certificates via the edge proxy acting as server and client (Hoffpauir: par. 0038 lawful intercept secrets engine 120 can [] include one or more certificate/private key sets of information, which can be used to decrypt intercepted encrypted traffic. In this example, LISE 120 includes CDN1 certificate/private key 121 and CDN2 certificate/private key 125).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Hoffpauir with the system/method of Inman, Saye and Wang to include decoding traffic from adjacent resources using the dummy certificates via the edge proxy. One would have been motivated to controlling traffic by using certificate to filter and decrypt encrypted traffic (Hoffpauir: par. 0038).
Regarding claim 3: Inman in view of Saye and Wang discloses the method of claim 1.
Inman in view of Saye and Wang does not explicitly disclose wherein the dummy certificates are self-signed Certificates.
However, Hoffpauir discloses wherein the dummy certificates are self-signed Certificates (Hoffpauir: par. 0046 generation and delivery of filter requests corresponding to an intercept target and acquisition of TLS certificates).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Hoffpauir with the system/method of Inman, Saye and Wang to include the dummy certificates are self-signed Certificates. One would have been motivated to controlling traffic by using certificate to filter and decrypt encrypted traffic (Hoffpauir: par. 0038).
Regarding claim 4: Inman in view of Saye and Wang discloses the method of claim 1.
Inman in view of Saye and Wang does not explicitly disclose wherein the dummy certificates comprise a transport layer service (TLS) certificate.
However, Hoffpauir discloses wherein the dummy certificates comprise a transport layer service (TLS) certificate (Hoffpauir: par. 0125 any traffic from a specific Content Delivery Network would be using a specific Transport Layer Security (TLS) Certificate).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Hoffpauir with the system/method of Inman, Saye and Wang to include the dummy certificates comprise a transport layer service (TLS) certificate. One would have been motivated to controlling traffic by using certificate to filter and decrypt encrypted traffic (Hoffpauir: par. 0038).
Regarding claim 11: Inman in view of Saye and Wang discloses the method of claim 1.
Inman in view of Saye and Wang does not explicitly disclose generating a transport layer security (TLS) connection between edge proxies of the air-gapped network using the dummy certificate.
However, Hoffpauir discloses generating a transport layer security (TLS) connection between edge proxies of the air-gapped network using the dummy certificate (Hoffpauir: par. 0049 the LISE 120, in step 284 generates and sends a request 286 for a TLS certificate and private key to key server 170 of CDN1 132 [] in step 290 key server 170 of CDN1 132 generates and sends response message 292 including a TLS certificate and private key to LISE 120).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Hoffpauir with the system/method of Inman, Saye and Wang to include generating a transport layer security (TLS) connection between edge proxies of the air-gapped network using the dummy certificate. One would have been motivated to controlling traffic by using certificate to filter and decrypt encrypted traffic (Hoffpauir: par. 0038).
Regarding claim 12: Inman in view of Saye and Wang discloses the method of claim 1.
Inman in view of Saye and Wang does not explicitly disclose wherein the TLS connection enables traffic inspection.
However, Hoffpauir discloses wherein the TLS connection enables traffic inspection (Hoffpauir: par. 0125 during an intercept the traffic would be inspected and if that traffic matched that certificate, it could be excluded partially or fully, e.g. based on filtering rules, from the intercept).
The motivation is the same that of claim 11 above.
Regarding claims 14-15: Claims 14-15 are similar in scope to claims 2-3, respectively, and are therefore rejected under similar rationale.
Regarding claim 16: Inman in view of Saye and Wang discloses the device of claim 13.
Saye further discloses wherein the metadata is provided to the edge proxies based on an established parent-child relationships between edge proxies in adjacent layers (Saye: page 9 (9/13) once edgeAgent is running and the deployment has been received, it will start pulling and starting he system and custom modules [] where the child layer is pointed to the parent layer to pull the images. If we look at the images on the child layer, we now see they are all pulled from the parent layer).
The motivation is the same that of claim 13 above.
Regarding claim 19: Inman in view of Saye and Wang discloses the device of claim 1.
Inman in view of Saye and Wang does not explicitly disclose wherein the operations further comprise generating a transport layer security (TLS) connection between edge proxies of the air- gapped network using the dummy certificate and wherein the TLS connection enables traffic inspection.
However, Hoffpauir discloses wherein the operations further comprise generating a transport layer security (TLS) connection between edge proxies of the air- gapped network using the dummy certificate (Hoffpauir: par. 0049 the LISE 120, in step 284 generates and sends a request 286 for a TLS certificate and private key to key server 170 of CDN1 132 [] in step 290 key server 170 of CDN1 132 generates and sends response message 292 including a TLS certificate and private key to LISE 120) and wherein the TLS connection enables traffic inspection (Hoffpauir: par. 0125 during an intercept the traffic would be inspected and if that traffic matched that certificate, it could be excluded partially or fully, e.g. based on filtering rules, from the intercept).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of Hoffpauir with the system/method of Inman, Saye and Wang to include the operations further comprise generating a transport layer security (TLS) connection between edge proxies of the air- gapped network using the dummy certificate. One would have been motivated to controlling traffic by using certificate to filter and decrypt encrypted traffic (Hoffpauir: par. 0038).
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 Fahimeh Mohammadi whose telephone number is (571)270-7857. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
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, Luu Pham can be reached at 5712705002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/FAHIMEH MOHAMMADI/ Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights