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
The instant application having Application No. 18/429,067 is presented for examination by the examiner. Claim 1 is amended. Claims 15 and 16 have been newly added. Claims 1-16 have been examined.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 has been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4 and 7-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Goehring (US 2024/0323163 A1) in view of Stubbs (US 2023/0387956 A1).
Regarding Claim 1
Goehring discloses:
A modular cybersecurity appliance physically attachable between an internal processing environment and at least one external network, the appliance comprising (Goehring ¶46: The security gateway is described as modular and positioned between internal OT/IT networks and external systems via a secure tunnel.): a demilitarized zone (DMZ) network configured for filtering of at least one of:
1) inbound data traffic associated with the internal processing environment, or
2) encrypted outbound data traffic in transit to at least one external network, based on a first set of one or more packet inspection rules (Goehring ¶27 and 46: The DMZ is explicitly disclosed with filtering and firewall components, and analyzes inbound and outbound communications.);
at least one cryptographic module configured for: encryption of the outbound data traffic (Goehring ¶25: The PQE module is a cryptographic component that performs outbound encryption before transmission.); and
decryption of the inbound data traffic (Goehring ¶25:Inbound encrypted data from the DMZ is decrypted by the PQE module before delivery.);
at least one next generation firewall (NGFW) configured for filtering of at least one of:
1) decrypted inbound data traffic admitted by the DMZ network, or
2) unencrypted outbound data traffic, based on a second set of one or more packet inspection rules (Goehring ¶47: The Next-Generation Firewall (NGFW) is explicitly named and described as inspecting traffic at OSI layers 2-7 using advanced filtering.); and
at least one security information and event management (SIEM) module configured for: receiving an event log from at least one of the DMZ network, the cryptographic module, or the NGFW; identifying at least one threat based on the at least one received event log (Goehring ¶42-45: discloses a syslog collector/log forwarder that receives system logs, and includes components like a lightweight IDS/IPS, an ICS protocol interpreter, and a honeypot, all of which analyze those logs or traffic for malicious activity and generate alerts upon detection. These functions collectively perform the same operations as a SIEM module.); and generating at least one alert corresponding to the at least one identified threat (Goehring ¶42-45: state that the IDS/IPS, ICS protocol interpreter, and honeypot module can generate alerts upon detecting suspicious or malicious activity, such as pattern matches or baseline deviations.),
Goehring teaches a modular cybersecurity gateway including a DMZ environment, cryptographic module, next-generation firewall, and security monitoring functionality implemented as discrete functional components within a security gateway positioned between internal and external networks (Goehring ¶20-27, 42-44). However, they do not disclose “a physical housing including at least one slot … wherein each of the DMZ network, the at least one cryptographic module, the at least one NGFW, and the at least one SIEM module occupy at least one slot within the physical housing.” On the other hand, Stubbs teaches a hardened physical housing including a backplane configured to receive multiple modular hardware components, wherein each component is implemented as a separate OpenVPX/SOSA-complaint module inserted into a corresponding backplane receptacle (i.e., slot) within the housing (Stubbs ¶16-21, Figs. 1-2B). It would have been obvious to one of ordinary skill in the art to implement the DMZ network, a DMZ environment, cryptographic module, next-generation firewall, and security monitoring functionality of Goehring as a separate modular cards occupying separate slots within the physically housing taught by Stubbs in order to improve modularity and field-upgradeability of the cybersecurity appliance, consistent with well-known design goals in deployable security systems.
Regarding Claim 2
Goehring discloses:
The modular cybersecurity appliance of Claim 1, wherein the at least one alert is a first alert, further comprising at least one out-of-band intrusion detection system (IDS) configured to:
1) monitor at least of the inbound data traffic and the outbound data traffic independently of the DMZ network and the NGFW (Goehring ¶42: teaches a separate IDS/IPS module that monitors network traffic independently of the DMZ and NGFW.);
2) identify at least one potential exploit based on the monitoring (Goehring ¶42: The IDS/IPS module analyzes network activity against known malicious patterns or signatures to detect threats, which includes identifying potential exploits such as malware, port scans, or buffer overflows based on monitored data.); and
3) generate at least one second alert corresponding to the at least one identified potential exploit (Goehring ¶42: describes that the IDS/IPS module generates alerts in response to detecting suspicious or malicious activity during monitoring, which includes alerts tied to identified potential exploits.).
Regarding Claim 3
Goehring discloses:
The modular cybersecurity appliance of Claim 2, wherein the at least one alert is a first alert, further comprising: at least one out-of-band intrusion prevention system (IPS) configured to execute at least one countermeasure in response to the at least one second alert (Goehring ¶42: teaches an out-of-band IPS that can block malicious traffic as a countermeasure triggered by alerts.).
Regarding Claim 4
Goehring discloses:
The modular cybersecurity appliance of Claim 1, further comprising: at least one cross-domain solution (CDS) configured for transmission and reception of data between the internal processing environment and the at least one external network across a security domain boundary (Goehring ¶31-32: The Q-SEC private tunnel applies zero-trust principles, strictly controlling transmission and reception between internal OT/IT and external system through inspection and authentication. The DMZ further enforces segmentation, making this a functional cross-domain solution.).
Regarding Claim 7
Goehring discloses:
The modular cybersecurity appliance of Claim 1, wherein filtering the inbound data traffic includes at least one of:
accepting the inbound data traffic;
rejecting the inbound data traffic (Goehring ¶25-27: teaches rejecting inbound data traffic by inspecting incoming communications in the DMZ and preventing their delivery if they violate security policies. For example, malicious or unauthorized content is explicitly blocked from reaching its destination.);
flagging the inbound data traffic; or
routing the inbound data traffic to at least one destination within the internal processing environment.
Regarding Claim 8
Goehring discloses:
The modular cybersecurity appliance of Claim 1, wherein filtering the outbound data traffic includes at least one of:
accepting the outbound data traffic; or
rejecting the outbound data traffic (Goehring ¶25: teaches rejecting outbound data traffic by analyzing outgoing messages for malicious or sensitive content and filtering them out before transmission. This ensures unauthorized information does not leave the protected environment.).
Regarding Claim 9
Goehring discloses:
The modular cybersecurity appliance of Claim 1, further comprising: at least one security orchestration automation and response (SOAR) module communicatively coupled to the at least one SIEM module, the at least one SOAR module configured for executing at least one countermeasure responsive to the at least one alert (Goehring ¶27-28: teaches that the system analyzes communications in the DMZ using firewalls, processors, and filters, and can automatically block or prevent communication when malicious content is detected or anomalous patterns are observed. This real-time enforcement in response to detected threats functions as a countermeasure triggered by SIEM-like alerting.).
Regarding Claim 10
Goehring discloses:
The modular cybersecurity appliance of Claim 1, wherein: the at least one SIEM module is configured for receiving an event log from at least one of a physical device or a system of one or more devices associated with the internal processing environment (Goehring ¶43-44: teaches that a syslog collector/log forwarder receives event logs from physical system within the internal environment and forwards them to a monitoring and alerting system, which serves a SIEM-like function. These logs are used to detect anomalies and generate alerts.).
Regarding Claim 11
Goehring discloses:
The modular cybersecurity appliance of Claim 10, wherein:
the internal processing environment is associated with a mobile platform (Goehring ¶34: teaches that the system operates within mobile platforms such as ships, trains, and semi-trucks, which house operational technology components and associated processing environments. These mobile assets are explicitly identified as hosting the system’s internal logic and communication infrastructure.); and
the at least one of a physical device or a system includes at least one sensor associated with the mobile platform (Goehring ¶28: teaches that mobile platforms (ships, trucks) include physical systems equipped with sensors such as those measuring temperature, pressures, and rotation speed. These sensors are part of the onboard operational technology used for real-time monitoring and analytics.).
Regarding Claim 12
Goehring discloses:
The modular cybersecurity appliance of Claim 10, wherein: the internal processing environment is associated with a mobile platform having at least one of a door or a window; and the at least one physical device or a system includes at least one lock configured to secure the door or the window (Goehring ¶17 and 34: describes mobile platforms such as ships, trucks, and trains which by their nature have doors and windows and include physical access control systems as part of the onboard safety and security infrastructure. A person of ordinary skill in the art would understand that such access control system include locks securing doors or compartments on these platforms.).
Regarding Claim 13
Goehring discloses:
The modular cybersecurity appliance of Claim 1, wherein: the internal processing environment is associated with a mobile platform; and the at least one physical device or a system includes at least one subsystem of the mobile platform (Goehring ¶34: teaches a modular cybersecurity system deployed in mobile platforms such as trucks, ships, and trains, which contain various onboard systems and subsystem that interact with the internal processing environment. These subsystem generate data and are explicitly part of the operational technology monitored by the appliance.).
Regarding Claim 14
Goehring discloses:
The modular cybersecurity appliance of Claim 1, comprising: one or more physical interfaces configured for connecting the appliance to at least one of the internal processing environment or the at least one external network,
each physical interface compatible with one or more protocols selected from a group including: an Ethernet network (Goehring ¶21: teaches that appliance (PQE module) connects to operational system using physical interfaces that support standard protocols including ethernet and fiber-optic connections.);
a fiber channel network; or
a MIL-STD-1553 data bus.
Regarding Claim 15
Goehring teaches a modular cybersecurity gateway including a DMZ environment, cryptographic module, next-generation firewall, and security monitoring functionality implemented as discrete functional components within a security gateway positioned between internal and external networks (Goehring ¶20-27, 42-44). However, they do not disclose “wherein the physical housing is a hardened chassis that is in compliance with Sensor Open Systems Architecture (SOSA) technical standards for interoperability.” On the other hand, Stubbs teaches a hardened physical housing including a backplane configured to receive multiple processing modules in compliance with SOSA technical standards, including use of 3U OpenVPX factors to ensure interoperability, ruggedization, and cross-platform compatibility (Stubbs ¶18-21, 27, Figs 1-2B). It would have been obvious to one of ordinary skill in the art to implement the modular cybersecurity appliance of Goehring withing the SOSA-complaint hardened chassis taught by Stubbs in order to achieve standardized interoperability, modular upgradeability, and rugged deployment consistent with defense and industrial cybersecurity environments.
Regarding Claim 16
Goehring teaches a modular cybersecurity gateway including a DMZ environment, cryptographic module, next-generation firewall, and security monitoring functionality implemented as discrete functional components within a security gateway positioned between internal and external networks (Goehring ¶20-27, 42-44). However, they do not disclose “wherein the DMZ network, the at least one cryptographic module, the at least one NGFW, and the at least one SIEM module each occupy a separate slot within the physical housing”. On the other hand, Stubbs teaches a hardened physical housing including a backplane configured to receive multiple processing modules in compliance with SOSA technical standards, wherein each module is implemented as a separate OpenVPX/SOSA-complaint card inserted into its own corresponding backplane slot within the physical housing (Stubbs ¶16-21, 27, Figs 1-2B). It would have been obvious to one of ordinary skill in the art to implement each of the DMZ network, a DMZ environment, cryptographic module, next-generation firewall, and security monitoring functionality of Goehring as a separate modular cards occupying separate slots within the physically housing taught by Stubbs in order to improve modularity and field-upgradeability of the cybersecurity appliance, consistent with well-known design goals in deployable security systems.
Claims 5 and 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Goehring (US 2024/0323163 A1), in view of Stubbs (US 2023/0387956 A1) as applied to claim 1 above, and in further view of Vuppalapati (US 2025/0103752 A1).
Regarding Claim 5
Goehring and Stubbs teaches a modular security gateway positioned between internal and external networks, incorporating a DMZ with filtering and firewall capabilities, a cryptographic module for encrypting outbound and decrypting inbound traffic, a Next-Generation Firewall for deep packet inspection, and log-analysis components (IDS/IPS) that collectively function as a SIEM by detecting threats and generating alerts. However, they do not disclose the following limitation “loss prevention (DLP) module configured for filtering at least one of: inbound data traffic admitted by the NGFW, or outbound data traffic received from the internal processing environment, based on a security classification associated with the inbound data traffic or outbound data traffic”
However, in an analogous art, Vuppalapati discloses a DLP system/method that includes:
The modular cybersecurity appliance of Claim 1, further comprising: at least one network data loss prevention (DLP) module configured for filtering at least one of (Vuppalapati ¶56-58: teaches a cloud-based DLP system that inspects network traffic and blocks content before it leaves the network. Vuppalapati ¶62: further describes where content is allowed or blocked based on predefined rules and triggers.):
inbound data traffic admitted by the NGFW, or
outbound data traffic received from the internal processing environment (Vuppalapati ¶114-115: teaches filtering outbound data traffic to prevent sensitive information being exposed outside the system.), based on a security classification associated with the inbound data traffic or outbound data traffic (Vuppalapati ¶20: teaches that outbound traffic is filtered based on its content being classified as sensitive using pre-defined DLP dictionaries, thereby associating a security classification with the outbound traffic.).
Given the teachings of Vuppalapati and Stubbs, a person having ordinary skill in the art would have found it obvious to modify the teaching of Goehring to incorporate a DLP module into a modular cybersecurity appliance to filter outbound traffic based on a content classification. Vuppalapati discloses a DLP system that scans outbound traffic for sensitive content and applies filtering policies accordingly, using a dictionary-based classification engine to determine whether data is considered sensitive. It would have been obvious to apply this classification-based filtering approach to outbound traffic in a modular system architecture, as such filtering ensures protection against data exfiltration. Moreover, applying the same classification logic to inbound traffic admitted by a NGFW would have been a routine and predictable extension to enhance bidirectional security coverage (Vuppalapati ¶114-115).
Regarding Claim 6
Goehring teaches a modular security gateway positioned between internal and external networks, incorporating a DMZ with filtering and firewall capabilities, a cryptographic module for encrypting outbound and decrypting inbound traffic, a Next-Generation Firewall for deep packet inspection, and log-analysis components (IDS/IPS) that collectively function as a SIEM by detecting threats and generating alerts. However, they do not disclose the following limitation “wherein the security classification is a first security classification, and the at least one DLP module is configured for: filtering at least one of the inbound data traffic or the outbound data traffic based on a deviation of the first security classification from a second security classification associated with the internal processing environment or the at least one external network”
However, in an analogous art, Vuppalapati discloses a DLP system/method that includes:
The modular cybersecurity appliance of Claim 5, wherein the security classification is a first security classification, and the at least one DLP module is configured for (Vuppalapati ¶56-58, 62: teaches a cloud-based DLP system that inspects network filtering and block sensitive data before it leaves the network. The filtering is performed according to predefined rules and DLP dictionaries.): filtering at least one of the inbound data traffic or the outbound data traffic based on a deviation of the first security classification from a second security classification associated with the internal processing environment or the at least one external network (Vuppalapati ¶43,45, 57, 62: detects when inbounds or outbound data traffic contains fields matching a sensitive data classification (first security classification) based on DLP dictionaries, and triggers filtering actions such as blocking, alerting, or forwarding to an ICAP server, when that data is found to deviate from acceptable classification thresholds which is defined by tenant policy for specific environments (second security classification). The system enforces filtering precisely when there is a mismatch between the classification of the data and the classification or trust level of the environment it is entering (internal vs external untrusted network.).).
Given the teachings of Vuppalapati, a person having ordinary skill in the art would have found it obvious to modify the teaching of Goehring and Stubbs to configure a DLP module to filter traffic based on deviation between two security classifications, one associated with data (first classification) and another associated with the network environment (second classification). Vuppalapati discloses that the system identifies data matching sensitive classification dictionaries and enforces filtering actions when the classification of the data deviates from policy threshold defined for the destination or source environment, such as a trusted internal network or an untrusted external network. It would have been obvious to use this deviation as a trigger for filtering as doing so enables policy-driven enforcement tailored to both content and context, thereby prevent data leakage across network boundaries (Vuppalapati ¶43, 45, 57, 62).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD A ABDULLAH whose telephone number is (571) 272-1531. The examiner can normally be reached on Monday - Friday, 8:30am - 5:00pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571) 272-2092. 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 http://pair-direct.uspto.gov. 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.
/SAAD AHMAD ABDULLAH/Examiner, Art Unit 2431
/LYNN D FEILD/Supervisory Patent Examiner, Art Unit 2431