Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments, see pages 7-12, filed on April 01, 2026, with respect to the rejection(s) of claim(s) 1, 2, 4-25 under 35 U.S.C. 103 as being unpatentable over YANAGIDA et al. (US 20180351913 A1 –hereinafter—“YANAGIDA”) in view of Bardgett US 9237125 B1 and in further view of Bartlett et al. (US 20060179296 A1—hereinafter—"Bartlett”) have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Miller et al. (US 20040111623 A1 –hereinafter –“Miller”).
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
a verification unit configured to compare messages in claim 1: lines 4, 10,
the verification unit is configured to recognize the same messages in claim 1: line 15
a central unit configured to generate an alert signal in claim 1: line 7
a verification unit configured to compare messages in claim 6: lines 6, 12,
the verification unit is configured to recognize the same messages in claim 6: line 17.
a central unit configured to generate an alert signal in claim 6: line 9.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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.
Claims 1, 2, 4-13, 15, 16 and 19, 23-25 are rejected under 35 U.S.C. 103 as being unpatentable over YANAGIDA et al. (US 20180351913 A1–hereinafter—“YANAGIDA”) in view of Miller et al. (US 20040111623 A1 –hereinafter –“Miller”) and in further view of Bartlett et al. (US 20060179296 A1—hereinafter—"Bartlett”).
As per claim 1:
YANAGIDA discloses a firewall configured to control messages transiting between two communication elements, said firewall comprising:
interfaces towards said communication elements (Figure 3: Interface 43 including Request and Response communication elements);
a verification unit configured to compare messages transiting between the two communication elements with data and to detect a lack of conformity of a message in transit with respect to said data ([0030] The blacklist method is a method of preventing attacks beforehand by checking a blacklist being information on an invalid (non-executable) parameter prestored in the web application firewall device against a parameter of a request and blocking the request when the checking results in matching. [0061] As shown in FIGS. 1 and 5, web application firewall device 3 receives a request from web client 9. Determination unit 31 of web application firewall device 3 determines whether or not the parameter of this request and the blacklist stored in storage unit 35 (first storage unit) match (first determination step S1); and
a central unit configured to generate an alert signal in case of detection by the verification unit of a lack of conformity of a message in transit ([0050] Generation unit 37 generates a signature for blocking an invalid parameter from the parameter error-handled by determination unit 31 or the invalid information. [0073] As shown in FIGS. 1 and 5, generation unit 37 generates a signature based on invalid information (S12) in order to filter a request including an invalid parameter from web client 9. In addition, generation unit 37 also generates a signature based on the error in step S3. Generation unit 37 transmits the generated signature to regulation unit 39),
wherein:
the verification unit is further configured to compare the messages transiting between the two communication elements with reference data which are contained in and a plurality of database and to detect a lack of conformity of a message in transit with respect to said reference data, said reference data comprise predetermined messages which are known and at least permitted values for fields of said predetermined messages ([0031] the whitelist method checks a whitelist being information on a valid (executable) parameter prestored in the web application firewall device against a parameter of a request and determines the request as an invalid parameter unless the comparison results in matching. [0065] Next, controller 51 receives the request including the parameter transmitted from web application firewall device 3. Controller 51 determines whether or not the request includes a valid parameter (second determination step S5). In other words, controller 51 determines whether or not the whitelist and the parameter of the request match);
the verification unit is further configured to recognize, between the messages transiting between the two communication elements, same messages as the messages of the reference data, and to compare with the reference data only the messages which are recognized ([0066] If the parameter of the request and the whitelist stored in storage unit 55 (second storage unit) do not match (NO in S5), controller 51 performs fault isolation in order to determine information such as which parameter is determined as not matching (S6) in a later operation. Controller 51 registers invalid information being information on a fault-isolated invalid parameter (S7). [0067] For example, as shown in FIG. 6, assume that the parameters of the whitelist are (x1, x2) and the parameters of the request are (x1, x2, x3), then the determination result is x1=valid, x2=valid, and x3=invalid. In the header of the response, the fact that x3 being an impossible parameter exists is registered as invalid information. Then, as shown in FIG. 5, controller 51 transmits a response including invalid information to response generation unit 53. [0069] If the parameter of the request and the whitelist stored in storage unit 55 match (YES in S5), controller 51 treats the request as valid information being information on a valid parameter. That is, in this web application device 5, controller 51 adopts a whitelist method. [0070] For example, as shown in FIG. 6, assume that the parameters of the whitelist are (y1, y2) and the parameters of the request are (y1, y2), then the determination result is y1=valid, and y2=valid. In the header of the response, a request including the parameters (y1, y2) is registered as valid information (S10 in FIG. 5). Then, as shown in FIG. 5, controller 51 transmits a response including valid information to response generation unit 53.).
YANAGIDA does not explicitly disclose the configured firewall between two communication elements is to control messages transitioning in a first direction and a second opposite direction between the two communication elements, and each of the plurality of databases comprises data relating to a specific type of message distinct from messages in other databases of the plurality of databases. Miller, in analogous art however, discloses the configured firewall between two communication elements is to control messages transitioning in a first direction and a second opposite direction between the two communication elements ([0064] FIG. 5 is a flow chart illustrating an example method whereby a protocol message gateway 122 can manage communication traffic in a network, such as enterprise network 110. First, in step 502, protocol message gateway 122 can receive a message and direct the received message to a protocol message parser 410, which can be configured to parse the message in step 504 and determine which of a set of protocol adapters 430 is appropriate for processing the message. As part of step 504, protocol message parser 410 can be configured to forward the message to a gateway manager 420 for further processing. [0073] Local client device 770 can communicate with remote server 780 by traversing enterprise network 710, the firewall 720, and external network 730 as shown by path 744. A proxy enforcer 750 can be used to ensure that messages traveling within network 710 use protocol message gateway 122. [0077] If client device 870 requests a suspect hostname through path 842, protocol message gateway 122 can be configured to give its own address as the corresponding address to that host thereby spoofing client 870 into believing protocol message gateway 122 is remote server 880. Protocol message gateway 122 can then relay messages to remote server 880 and monitor and regulate communications therewith. If the hostname is not know to be one belonging to a certain server, e.g., a server associated with a target protocol, the gateway 122 make a request to external nameserver 890 through path 844 and respond to client device 870 with the response given by external nameserver 890); and
each of the plurality of databases comprises data relating to a specific type of message distinct from messages in other databases of the plurality of databases ([0043-0044]Proxy enforcer 250 can be configured to then passively listen to messages as they flow, e.g., through firewall 220. Proxy enforcer 250 can comprise a set of proxy enforcement rules 252, e.g., maintained in an enforcement rules database 256. When proxy enforcer 250 intercepts an IM message, i.e., a message that uses a target protocol, proxy enforcer will match the IM message using the proxy definition files 254. Proxy enforcer 250 can then execute the associated enforcement rule 252. The enforcement rule 252 can be configured to override aspects of the IM protocol associated with the intercepted IM message. For example, proxy enforcement rules 252 can require that IM messages pass through the protocol message gateway 240, which can be configured to act as a proxy for all IM messages. Proxy enforcer 250 can be configured to then prevent the message from being effective if it does not adhere to proxy enforcement rules 252. One way proxy enforcer 250 can prevent a message 270 from being effective is to kill the communication connection between the service of the message and the destination, whether or not the message originates in enterprise network 210 or in external network 230. In alternative embodiments, proxy enforcer 250 can be configured to reset the communication connection associated with the message. [0050] Thus, proxy enforcer 250, or similarly proxy enforcer 150, can be configured to ensure messages that use a target protocol pass through protocol message gateway 122. [0051] Firewall 120 can be configured to then redirect, in response to recognition patterns 124, at least some of the messages it processes to protocol message gateway 122. In one embodiment, for example, messages can be redirected using a conventional content vectoring protocol (CVP) technique, in which, after processing the message and determining that it should be further processed by protocol message gateway 122, firewall 120 delivers the message to protocol message gateway 120).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the configured firewall between two communication elements disclosed by Bardgett is to include the configured firewall between two communication elements is to control messages transitioning in a first direction and a second opposite direction between the two communication elements, and each of the plurality of databases comprises data relating to a specific type of message distinct from messages in other databases of the plurality of databases. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a protocol management system that is capable of detecting certain message protocols and applying policy rules to the detected message protocols that prevent intrusion, or abuse, of a network's resources, using a protocol message gateway that is configured to apply policy rules to high level message protocols, such as those that reside at layer 7 of the ISO protocol stack as suggested by Miller ([0009-0011]).
YANAGIDA and Miller do not explicitly disclose the firewall further comprising at least one transmission interface configured to transmit alert signal to at least one alert signal management device. Bartlett, in analogous art however, discloses the firewall further comprising at least one transmission interface configured to transmit alert signal to at least one alert signal management device ([0017] The application monitor in the passive mode performs loosely coupled cooperative processing with the near-proximity application firewall(s) by offloading processing of security violation detection, security violation alerts, security violation logging, escalation alerts, and/or escalation logging for the observed application(s). Alternatively, the application monitor in the passive mode performs tightly coupled cooperative processing with the near-proximity application firewall(s) by offloading processing of security violation alerts, security violation logging, and/or escalation logging for the observed application(s). [0085] In the event of a violation detected at the application monitor 1030, an escalation alert is relayed directly to the application firewalls 1020, 1022, and 1024, escalating the application firewalls 1020, 1022, and 1024 to their respective designated higher Operational Modes (Active Mode is recommended in this case) for the period of time established in the escalation rules; the application monitor 1030 also relays the escalation alert to the Security Console 1050 (which, in turn, will relay the escalation alert to other security nodes in the CPES 1000 according to the escalation rules). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed firewall disclosed by YANAGIDA and Miller do to include the firewall further comprising at least one transmission interface configured to transmit alert signal to at least one alert signal management device. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a robust application firewall with throughput and coordination of real-time and near-real-time response to application-layer attacks and sensitive data misuse as suggested by Bartlett ([0010-0011).
As per claim 2:
YANAGIDA and Miller in view of Bartlett disclose the firewall of claim 1, wherein the firewall is configured to control messages of an application layer of a communication model used for the communication between the two communication elements (Bartlett [0040] An "application monitor," inspecting the same application-layer in-bound and out-bound traffic with the same security violation policies as an application firewall, except in near real-time (without being situated directly in-line with the subject application), can therefore effectively participate in a CPES).
As per claim 4:
YANAGIDA and Miller in view of Bartlett disclose the firewall according to claim 1, wherein the reference data is transcribed into a computer format exploitable by the verification unit (Bartlett [0067] rules are stored locally at each participating security node to minimize latency and reaction time, in whatever representation format (XML, proprietary flat file, encrypted, etc.) is best suited to the individual node; rules may be duplicated or centralized at the security console or escalation hub controller(s) to enhance policy management, persistence, auditability, efficiency, usability, etc. Similarly, communication protocols for peer-to-peer, hub-and-spoke, waterfall, store-and-forward or other indirect relay dissemination of escalation triggers, alerts, de-escalation commands, etc., can be implemented and configured in numerous ways, as such implementation alternatives are readily apparent to those skilled in the art).
As per claim 5:
YANAGIDA and Miller in view of Bartlett disclose the firewall according to claim 1, wherein the reference data is representative of the information to be exchanged between the communication elements (YANAGIDA [0057] In addition, when a whitelist and a parameter of a request match, controller 51 registers valid information being information on a detected valid parameter in a header of a response. [0069] If the parameter of the request and the whitelist stored in storage unit 55 match (YES in S5), controller 51 treats the request as valid information being information on a valid parameter. That is, in this web application device 5, controller 51 adopts a whitelist method).
As per claim 6:
Claim 6 is directed to a communication system comprising at least one communication element, comprising a firewall configured to control messages transitioning in at least one direction between two communication elements having substantially similar limitations according to claim 1 and therefore claim 6 is rejected with the same rationale given above to reject 1.
As per claim 7:
YANAGIDA and Miller in view of Bartlett disclose the communication system of claim 6, comprising at least one database containing reference data, said reference data comprising predetermined messages and at least permitted values for fields of said predetermined messages (Bartlett [0070] For example, as shown in FIG. 6, assume that the parameters of the whitelist are (y1, y2) and the parameters of the request are (y1, y2), then the determination result is y1=valid, and y2=valid. In the header of the response, a request including the parameters (y1, y2) is registered as valid information (S10 in FIG. 5). Then, as shown in FIG. 5, controller 51 transmits a response including valid information to response generation unit 53.
As per claim 8:
YANAGIDA and Miller in view of Bartlett disclose the communication system of claim 6, further comprising an alert signal management device configured to generate an action in case of reception of an alert signal from the firewall (Bartlett [0071] An Active Mode is the highest level of the Operational Mode hierarchy 400, and is only applicable to application firewalls and data security enforcement points. In addition to performing all of the tasks associated with Bypass and Passive Modes, application firewalls operating in Active Mode perform intrusion prevention tasks according to their respective security rules. These tasks are usually characterized by the ability to block, redirect, correct or otherwise manipulate in-bound and/or out-bound application traffic deemed malicious or flawed according to security policy. The application firewall may optionally watermark in-bound traffic via a mechanism such as a hash algorithm as part of a scheme to prevent circumvention of the application firewall according to security policy. In addition to performing all of the tasks associated with Bypass and Passive Modes, data security enforcement points operating in Active Mode perform data change and disclosure prevention tasks according to their respective security rule).
As per claim 9:
YANAGIDA and Miller in view of Bartlett disclose the communication system of claim 8, wherein the alert signal management device is configured to prevent a detected non-conforming message from passing (Bartlett [0017] The application monitor in the passive mode performs loosely coupled cooperative processing with the near-proximity application firewall(s) by offloading processing of security violation detection, security violation alerts, security violation logging, escalation alerts, and/or escalation logging for the observed application(s). Alternatively, the application monitor in the passive mode performs tightly coupled cooperative processing with the near-proximity application firewall(s) by offloading processing of security violation alerts, security violation logging, and/or escalation logging for the observed application(s). The passive mode includes the step of transmitting peer-to-peer escalation triggers directly to the tightly coupled application firewall(s) in the event that the detected security violation matches one or more of a pre-defined set of escalation rules. [0076] In the event of a violation detected at either the application firewalls 620 or the application monitor 630, an escalation alert is relayed through the Security Console to the application firewalls 622, escalating the application firewalls 622 to its designated higher Operational Mode for the period of time established in the escalation rules. It should be noted that a violation at the application monitor 630 might set the application firewalls 622 to Active Mode, while a violation at the application firewalls 620 might set the application firewalls 622 only to Passive Mode, according to the level of risk deemed acceptable by the system administrator when the escalation rules were designed).
As per claim 10:
YANAGIDA and Miller in view of Bartlett disclose the communication system of claim 8, wherein the alert signal management device is configured to generate an action depending on the detected non-conforming message (Bartlett [0070] A Passive Mode is the second level of the Operational Mode hierarchy 400. In addition to performing all of the tasks associated with Bypass Mode, security nodes operating in Passive Mode perform malicious behavior detection tasks, examining the in-bound application traffic and/or data requests against their respective escalation security rules to detect possible violations of interest across applications, logical application-layer groups and/or distributed site locations. Each detected violation may optionally be sent to the Security Console as an alert. Security nodes operating in Passive Mode may optionally produce logs of activity (e.g. alerts, transactions, changes in Operational Mode, statistics, etc.) for later audit and forensics analysis. If escalation rules are on for the security node at the Passive Mode level, an escalation alert will be sent to the Security Console and to any other tightly-coupled (or peer-to-peer) security node when a violation is detected. Passive Mode operation provides lower latency for application firewalls than Active Mode. Latency and CPU consumption may be further reduced by turning off logging and/or escalation rules for the application firewall. Passive Mode will be the usual default in the Operational Mode hierarchy for application monitors, as latency is not an issue. Passive Mode is also the usual default for data security enforcements points participating in a CPES environment, as normal encryption/decryption occurs while both receiving and/or detecting escalation events).
As per claim 11:
YANAGIDA and Miller in view of Bartlett disclose the firewall communication system of claim 6, comprising at least one auxiliary firewall (Bartlett [0075] FIG. 6 illustrates a loosely coupled default configuration CPES 600 according to an embodiment of the invention. Particularly, the CPES 600 comprises a network firewall 610, a router 615, one or more application firewalls 620 (AF1) in Active Mode with logging providing intrusion prevention for HTTPS application traffic to and from one or more Web servers 640, one or more application firewalls 622 (AF2) in Bypass Mode directing HTTP application traffic to and from one or more Web servers 642; an application monitor 630 (AM1) in Passive Mode with logging providing intrusion detection for the same Web servers 640 and 642, and a Security Console 650).
As per claims 12 and 13:
Claims 12 and 13 are directed to a method for treating and filtering messages transiting in at least one direction between two communication elements, said method having substantially similar corresponding limitation features of claims 1 and 8 respectively and therefore claims 12 and 13 are rejected with the same rationale given above to reject corresponding limitations of claims 1 and 8.
As per claims 15, 17 and 19: YANAGIDA and Miller in view of Bartlett disclose the firewall according to claim 14, wherein the alert signal management device is configured to generate different actions dependent upon the type of a message for a detected lack of conformity (Bartlett [0070] A Passive Mode is the second level of the Operational Mode hierarchy 400. In addition to performing all of the tasks associated with Bypass Mode, security nodes operating in Passive Mode perform malicious behavior detection tasks, examining the in-bound application traffic and/or data requests against their respective escalation security rules to detect possible violations of interest across applications, logical application-layer groups and/or distributed site locations. Each detected violation may optionally be sent to the Security Console as an alert. Security nodes operating in Passive Mode may optionally produce logs of activity (e.g. alerts, transactions, changes in Operational Mode, statistics, etc.) for later audit and forensics analysis. If escalation rules are on for the security node at the Passive Mode level, an escalation alert will be sent to the Security Console and to any other tightly-coupled (or peer-to-peer) security node when a violation is detected. Passive Mode operation provides lower latency for application firewalls than Active Mode. Latency and CPU consumption may be further reduced by turning off logging and/or escalation rules for the application firewall. Passive Mode will be the usual default in the Operational Mode hierarchy for application monitors, as latency is not an issue. Passive Mode is also the usual default for data security enforcements points participating in a CPES environment, as normal encryption/decryption occurs while both receiving and/or detecting escalation events).
As pe claims 23-25: YANAGIDA and Miller in view of Bartlett disclose the firewall according to claim 1, said reference data comprise predetermined messages and specific permitted values for fields of said predetermined messages, wherein said specific permitted values are selected from the group consisting of value ranges, minimum values, maximum values, data types, and field sizes (Bartlett [0014] In an embodiment of the invention, the passive mode includes examining in-bound or out-bound application-layer traffic to detect escalation rule violations and/or data access requests and/or user data access behavioral patterns to detect escalation rule violations. The passive mode may further include receiving the escalation triggers).
Claims 20-22 are rejected under 35 U.S.C. 103 as being unpatentable over YANAGIDA et al. (US 20180351913 A1–hereinafter—“YANAGIDA”) in view of Miller et al. (US 20040111623 A1 –hereinafter –“Miller”) and in further view of Bartlett et al. (US 20060179296 A1—hereinafter—"Bartlett”) in view of Bardgett US 9237125 B1.
As per claims 20-22 : YANAGIDA and Miller in view of Bartlett do not explicitly disclose the firewall, wherein the verification unit comprises a Field-Programmable Gate Array. Bardgett, in analogous art however, discloses the firewall according to claim 1, wherein the verification unit comprises a Field-Programmable Gate Array (FPGA) ( Bardgett: Column 10: lines 7-13: 31) In an embodiment, the implementation methods can be demonstrated using at least one content conversion in combination with a protocol translation and an encapsulation method with command, control and viewing mechanisms, implemented in two separate modules which could be realized in real or virtual machines (VMs) on the same hardware, such as an FPGA or multi-chip logic board or physically separate hardware). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the configured firewall between two communication elements disclosed by YANAGIDA and Miller in view of Bartlett is to include control messages transitioning in a first direction and a second opposite direction between the two communication elements. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a network security device which protects a user's computer from a direct effects of software sent from a server by converting data to a non-volatile information stream using two or more firewall isolation stages using a multistage functionality that decouples the information communicated from bulk of data sent from the server by converting the data into non-volatile information to eliminates risk from the most aggressive adaptive malware by using an intermediate protocol translation between two of the stages contained in the decoupling firewall as suggested by Bardgett (in column 5: lines 1-10).
BRI (Broadest Reasonable Interpretation)
The above claims under examination have been given their BRI consistent with the applicant’s disclosure as they would be interpreted by one of ordinary skill in the art at the time of filing of the invention. In order to construe, appraise boundary and scope of the claimed limitations, the following claim words or terms or phrases or languages have been given to them their BRI considerations and context in view of the applicant’s disclosure. For example, for the following claim words or terms or phrases or languages, the examiner recites BRI considerations from the applicant’s disclosure as follows:
Communication Element [Applicant’s Disclosure: ¶0003] communication element means any computer element such as a computer, a computer network, etc., which is capable of communicating with another computer element, by being capable of transmitting and/or receiving messages; and message means an assembly of data transmitted from one communication element to another. [¶0038] In the context of the present invention, a communication element may correspond to any computer element (such as a computer, a computer network, e.g. a local area network (LAN), etc.) which is able to communicate with another computer element, i.e. which is able to transmit and/or receive messages from the latter.
Database [Applicant’s Disclosure: ¶0055] A database is any electronic means, such as a memory, which is part of the communication system 4 and which allow to store the assembly of the data necessary for allowing the verification unit 7 to carry out the intended comparisons.
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure.
MANTIN et al ( US 20210203641 A1) describes a web application security proxy, such as a web application firewall, that watches requests moving between web clients and web servers. It applies a baseline set of security rules to incoming web traffic and records which rules were triggered recently. It then uses a prediction model to guess which other rules are likely to be triggered next. Those predicted rules are turned on before the next wave of traffic arrives. The idea is to keep stricter rules normally turned off, so they do not create too many false alarms. When the traffic pattern suggests an attack is progressing, the system temporarily enables the stricter rules. The prediction model can be built from past sequences of triggered rules. The specification describes both a natural-language-style sequence model and a Bayesian conditional-probability approach. The system may also deactivate rules later if they are no longer likely to be needed. The same technique may be implemented by the proxy itself or by a separate security manager.
ARIMANDA et al (US 20220329532 A1) describes a network security device, such as a firewall, that decides whether to let traffic pass based on an “application path” found in the traffic. The device first receives network traffic tied to a session between devices on a network. It then extracts the application path from the traffic, identifies an application path identifier for that path, and looks up policy information tied to that identifier. Based on that policy, the device decides whether the traffic is allowed or blocked. If allowed, it forwards the traffic or otherwise permits communication; if not, it drops or blocks it. The application path may reflect a protocol stack, including application and communication protocol layers. The mapping from applications to application path identifiers may use wildcard-like path segments. The policy mapping can include both ordinary applications and application path identifiers. The goal is to control traffic more specifically than by protocol alone. The device may also log the path identifier and the policy decision. Example protocols include DNS, HTTP, SSL, TLS, QUIC, UDP, TCP, and SOCKS.
ANAND et al.( US 20210200884 A1) is about tracking who accessed what data through a web application and its database. It uses runtime agents inside the application stack to collect context from multiple stages of a request. First, a web application firewall examines incoming web traffic and adds security-related metadata. Then the web application or microservice adds its own user and request context. That context is either attached directly to the database query as serialized metadata or carried through the system using a trace identifier. When the database query runs, a database activity monitor captures additional database-side context. All of this information is stored together in a security data store or SIEM. A security administrator can then see which web user caused a database access. The system is meant to make audits, investigations, and anomaly detection easier. It also helps distinguish legitimate users from suspicious or compromised ones.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
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, LINGLAN EDWARDS can be reached on (571) 270-5440. 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.
/TECHANE GERGISO/Primary Examiner, Art Unit 2408
Prosecution Insights