Analysis of

CLAIM 1 of US 6,839,751
Versus
US 5,793,763

1
US6839751
Assignee: Hi/fn, Inc.
Title: Re-using information from data transactions for maintaining
statistics in network monitoring
Filing Date: 2000-06-30
Publication Date: 2005-01-04
Inventor: Dietz, Russell S.; Maixner, Joseph R.; Koppenhaver, Andrew A.
Earliest Priority: 1999-06-30 US 60141903
Fee Status: 2017-12-06 Petition Related to Maintenance Fees Granted.
Legal Status (PAIR): Patented Case

Claim 1:

2
1 A method of analyzing a flow of packets passing through a connection The invention described by the ‘763 Patent provides for monitoring and analyzing a
point on a computer network, the method comprising: flow of packets passing through a connection point on a computer network.

Specifically, Mayes ‘763 analyzes a flow of packets passing through a connection point
on a computer network. Mayes ‘763 abstract (“ Packets arriving from the internet are
screened by an adaptive security algorithm.”)

More specifically, packets passing through the connection point are analyzed by an
adaptive security algorithm. For example, the flow diagram at Figure 5 of the patent
depicts the key steps in the analysis of the packets:

See also the discussion of the processing of the flow of packets depicted in Fig. 5 at
Mayes ‘763 at 8:25-51.

As described in Fig. 5 and in the detailed description in the ‘763 patent, the initial step
in the flow waits for an inbound packet to be received at the connection point. The
subsequent steps analyze each packet that is received.

Similarly, the ‘763 patent analyzes outbound packets passing through the connection
point. Mayes ‘763 at 2:38-41 (“Fig. 3 is a process flow diagram showing generally the

3
steps involved in transmitting an outbound packet through a NAT system to the
Internet in accordance with this invention.”) See also, Figure 3 of the ‘763 patent:

4
(a) receiving a packet from a packet acquisition device coupled to the The ‘763 patent describes an I/O circuit residing between a private network and an
connection point; external network. Packets inbound for address locations on the private network are
received by the I/O circuit; Outbound packets from the private network to addresses on
the external network are received by the I/O circuit. The I/O circuit and/or the private
network interface or the external network interface described in Figure 1 of the patent
are “packet acquisition devices”.

Mayes ‘763 at 4:8-54.

Section 3 of the Description of the Preferred Embodiments (starting at Column 5, line

35) describes a process “upon receipt of packet from enterprise network” (Mayes ‘763
at 5:42-43).

The system described by the ‘763 patent receives both “inbound” and “outbound”
packets coupled to the connection point.

For packets inbound from the Internet, the connection point awaits receipt of a packet
and, upon receipt of such a packet, processes that packet. Mayes ‘763 at 8:53-56
(“Process 200 begins at 202 and then a decision step 204 determines whether an
inbound packet has been received. If not, the system simply awaits receipt of such
packet.”)

Packets outbound from the enterprise network are also received at the connection
point. Mayes ‘763 at 5:41-48 (“Fig. 3 details a process that may be employed by
network address translation system 34 upon receipt of a packet from enterprise
network 36. Such outbound packets are received at the inside interface 18a of system
34. The process begins at 94 and in a decision step 96 determines whether an
outbound packet has been received from a host on enterprise network 36. If not, the
system simply awaits receipts of such packet.”)

5
(b) for each received packet, looking up a flow-entry database for
containing one or more flow-entries for previously encountered
conversational flows, the looking up to determine if the received
packet is of an existing flow,
Packets received by the process described in the ‘763 patent are examined to
determine if the packet is part of a previously logged conversational flow. Note that the
‘751 patent describes a conversational flow that includes an exchange of packets in
any direction from two network entities. In the context of the ‘763 patent, this “flow”
involves packets received by the system that are “outbound” from a network entity on
the enterprise network to a host on the Internet, and also packets in a conversational
flow that are “inbound” from the Internet to a host on the enterprise network. Thus, both
“inbound” and “outbound” packets in Mayes ‘763 are “received packets” in the context
of the ‘751 patent.
As described below, the processing of both the “inbound” and “outbound” packets meet
the limitations of this step.
First, for “outbound” packets that are received at the connection point, the system of
the ‘763 patent performs a lookup in a “translation slot” table to determine whether the
received packet is of an existing flow. Mayes ‘763 at 5:44-52 (“The process begins at
94 and in a decision step 96 determines whether an outbound packet has been
received from a host on enterprise network 36. If not, the system simply awaits receipt
of such packet. If, on the other hand, such packet was indeed received, a decision step
98 determines whether the host sending the packet is listed in a table of allocated
translation slots. This table includes a list of global and local IP addresses for all hosts
that have a translation slot opened.”)
Decision step 98 determines whether the host sending the packet is listed in a table of
allocated translation slots. A person of ordinary skill in the art would understand this
step to include a lookup. Person of ordinary skill in the art would also understand that
the table of allocated translation slots is a database of flow-entries. See also, Mayes
‘763 at 7:20-21 (“In practice, the translation slot takes the form of a data structure
stored in memory of the NAT system.”)
Similarly, for “inbound” packets that are received at the connection point, the system of
the ‘763 patent performs a lookup in a connection table to determine whether the
received packet is of an existing flow. Mayes ‘763 at 8:53-58 (“Process 200 begins at
202 and then a decision step 206 determines whether a translation slot exists for the
global IP destination address on the packet.”)
6
a conversational flow including an exchange of a sequence of one or
more packets in any direction between two network entities
For the purposes on this claim chart, “conversational flow” is construed to mean a
sequence of packets that are exchanged in any direction as a result of an activity (for
instance, the running of an *application* on a server as requested by a client). It is also
understood that some "conversational flows" may involve more than one connection,
and some may even involve more than one exchange of packets between a client and
server.
The ‘763 Patent clearly describes the processing of a “conversational flow” as
construed above. In the stateful firewall described in the ‘763 Patent, sequences of
packets are exchanged in both the outbound (i.e. from the private network to the public
network) as well as the inbound direction (i.e. from the public network to the private
network).
The flow of packets inbound to the private network or outbound from the private
network to the enterprise network include “an exchange of a sequence of one or more
packets in any direction between two network entities.” Figure 3 of the ‘763 patent
describes generally, the processing of packets outbound from the private network to
the enterprise network. Mayes ‘763 at 2:38-41 (“Fig. 3 is a process flow diagram
showing the steps involved in transmitting an outbound packet through a NAT system
to the Internet in accordance with this invention.”
Similarly, Figure 5 of the ‘763 patent describes, generally, the processing of packets
inbound to the private network. Mayes ‘763 at 2:46-48 (“Fig 5 is a process flow
diagram showing generally how an inbound packet is treated by a NAT system of this
invention.)
The “translation system” described in the ‘763 patent serves as a connection between
the external network and the internal enterprise network.
Packets traversing the connection, in particular those flowing in the outbound direction,
are clearly the result of an activity initiated by a client in the enterprise network (such
as initiating an FTP connection with a host on the external network or initiating a DNS
lookup). See, generally, Mayes ‘763 at 2:53-61 (describing Fig. 7, Fig. 8 and Fig. 9 as
flow diagrams for the processing of UDP, TCP and FTP packets, respectively).
The firewall described by the ‘763 Patent also clearly provides that each
“conversational flow” may involve more than one connection. This can be seen most
clearly at Column 7, lines 33-38 of the ‘763 Patent, where the inventors describe the
fact that each “translation slot” (which relates to a specific host/client pair) may involve
more than one “connection”:
7
As noted above, the construction of “conversational flow” includes the recognition that
some of such flows “may even involve more than one exchange of packets between a
client and a server.” As discussed below, the FTP connection processing described in
the ‘763 patent meets this limitation.

Any valid FTP connection that is recognized and processed by the translation system
of the ‘763 patent will involve more than one exchange of packets between a client and
a server, namely the exchange of FTP control packets and a separate exchange of
FTP data packets. Since an FTP connection is clearly one possible type of connection
handled by the translation system of the ‘763 patent, it follows that the overall
translation system is one where some conversational flows involve more than one
exchange of packets between a client and server.

First, the ‘763 patent clearly discloses an FTP connection as one of the many different
connection types handled by the translation system of the ‘763 patent. This can be
seen in the abstract (“In addition, FTP data packets are allowed to enter the local
network, but only after it has been established that their destination on the local
network initiated an FTP session.” See also, Mayes ‘763 at 12:44-57.

Second, the translation system of the ‘763 patent exchanges sequences of packets
where there can be more than one connection associated with a particular translation
slot. Mayes ‘763 at 7:31-36 (“A ‘connection’ field 138 contains a listing of the
connection slots, if any, appended to the translation slot. More than one connection
slot may be associated with a given translation slot…”)

Third, the FTP connections processed by the translation system of the ‘763 patent
involve conversational flows that involve more than one exchange of packets between
a client and a server. We see this in several places in the ‘763 patent. First, at
Column 8, lines 35-40:

8
As described in the passage above, the second adaptive security rule followed by the
system is one where an FTP data connection will only be initiated to a particular
translation slot after the system has determined that an FTP control connection already
exists between the internal and external network hosts. Thus, it should be clear that
the processing of FTP packets involves two separate connections associated with the
same translation slot, namely the FTP control connection and a separate FTP data
connection.

We see this described again at Column 12, line 58 through Column 13, line 4:

9
 As noted in the first highlighted passage, an FTP session consists of two connections.
The fact that the translation system described by the ‘763 patent establishes and
tracks these as two separate connections can be seen in the passage highlighted at
Column 13, lines 13-18. As noted in the passage, a new connection slot is created for
the inbound FTP data packet if one or more additional connection slots are available.
This only happens if a separate FTP control connection slot has already been
established. Mayes ‘763 at 13:4 (“Assuming that an FTP control connection slot
exists…”) These two separate “connection slots” are associated with a single record in
the translation slot database. See the description of the two separate but related data
structures earlier in this chart. See also Mayes ‘763 at 13:15-18 (“…process step 308
creates a new connection slot for the inbound FTP data packet… Concurrently
therewith, the new connection is registered in the “connection field” of the translation
slot.”)

Thus, the exchange of packets through the connection point is a “conversational flow”
as construed.

10
as a result of a particular activity using a particular layered set of one
or more network protocols,
a conversational flow further having a set of one or more states,
including an initial state;
11
The conversational flows analyzed by the process described in the ‘763 patent include
a layered set of one or more network protocols, including “DNS” packets, “ICMP”
packets, “TCP” packets and packets that are part of an “FTP” transmission. See,
generally, Mayes ‘763 at 2:53-61 (describing Fig. 7, Fig. 8 and Fig. 9 as flow diagrams
for the processing of UDP, TCP and FTP packets, respectively).
The adaptive security algorithm taught by the ’73 patent includes analysis of TCP and
UDP packets. Mayes ‘763 at 8:25-52.
The adaptive security algorithm taught by the ’73 patent includes analysis of FTP
packets. Mayes ‘763 at 12:44-57.
A person of ordinary skill in the art would understand that the TCP/IP protocol is a
layered network protocol, consisting of the following four layers:
• Application Layer.
• Transport Layer.
• Internet Layer.
• Network Access Layer.
The conversational flows analyzed by the process described in the ‘763 patent include
at least an initial state and subsequent states.
In the ‘763 patent, the “state” of a connection is defined by the parameters of the
Translation slot (and possibly associated Connection slot) entries associated with a
particular conversational flow. The absence of an entry for a particular conversational
flow indicates to the system that the conversational flow has not been previously
encountered and, as such, an “initial state” must be created. Thereafter, the system of
the ‘763 patent examines each inbound and/or outbound packet and updates the
“state” of the conversational flow by updating entires in the Translation slot and
Connection slot data structures.
When a new conversational flow is detected, entries are made in the connection table
of the ‘763 patent that define key parameters of the the connection. Processing of
subsequent packets identified as belonging to that same conversation will result in
subsequent states of the same conversational flow.
For example, when a new connection is detected and the system determines that a
free translation slot is available, process step 108 allocates a translation slot and the
 NAT system fill the slot with “various pieces of relevant information”. Mayes ‘763 at
6:16-27:

The ‘763 patent discloses the tracking of state information regarding each
conversational flow. The system of the ‘763 patent maintains two related tables, a
“Translation Slot” table and a “Connection Slot” table. Mayes ‘763 at 2:42-45
(identifying Figs. 4a and 4b as the Transalation Slot and Connection Slot data
structures, respectively.).

The Translation Slot table is a data structure stored in the memory of the NAT system
that contains information regarding the state of existing conversational flows being
maintained by the system. Mayes ‘763 at 7:18-32:

12
 Even more detailed state information about a particular conversational flow is
maintained in the related Connection table. Each Translation Slot may have one or
more connection slots associated with the given translation slot. Mayes ‘763 at 7:31-36
(“A ‘connection’ field 138 contains a listing of the connection slots, if any, appended to
the translation slot. More than one connection slot may be associated with a given
translation slot…”)

A person of ordinary skill in the art would recognize the data elements maintained in
the Translation Slot and related Connection Slot data structures define the “state” of
the conversational flow.

The “various pieces of relevant information” comprise a set of data elements that
define the current state of the conversational flow. These elements are listed at Figs.
4a and 4b and are described in detail at Mayes ‘763 at 7:8-59 (for the Translation slot
state table) and at Mayes ‘763 at 7:60 through 8:24. The state table entries uniquely
identify the conversational flow when it is initially set up. Mayes ‘763 at 7:25-32 (“A
‘global’ field 134 provides the gllbal unique IP address temporarily held by the host
having the translation slot. A ‘local’ address field 136 specifies the local address of the
host. The global and local address fields are set when the translation slot is opened
and they remain fixed throughout the life of the slot.”)

Detailed state information is provided by the remaining entires in the Translation slot
data structure. For example, a “flags” field contains flags that may be set in connection
with a particular translation slot. Mayes ‘763 at 7:46-59.

When a new conversational flow is encountered and the initial entries in the
Translation slot table are made, such information would be recognized as reflecting the
initial state of the conversational flow.

As the conversational flow progresses (i.e. packets are exchanged), the information in
the translation slot and connection slot table entries is updated, reflecting subsequent
states of the conversational flow.

13
(c) if the packet is of an existing flow,
identifying the last encountered state of the flow,
performing any state operations specified for the state of the flow,
14
The process described in the ‘763 Patent examines each inbound and outbound
packet to determine whether the packet is of an existing flow. Mayes ‘763 at 5:48-51
(“If, on the other hand, such packet was indeed received, a decision step 98
determines whether the host sending the packet is listed in a table of allocated
translation slots.”) See also, Mayes ‘763 at 8:55-58 (“When such a packet is received,
a decision step 206 determines whether a translation slot exists for the global IP
destination address on the packet.”)
When the packet is from a previously encountered flow, the last encountered state is
identified. Mayes ‘763 at 5:61-64 (“Assuming that step 98 is in fact answered yes (i.e.
the translation slot table lists the local IP source address on the packet), a process
step 106 examines the actual translation slot for the local host identified in the
translation slot table.”) A person of ordinary skill in the art would recognize that
“examin[ing] the actual translation slot” involves retrieving the state data stored in the
Translation slot data structure described earlier. This retrieval identifies the last
encountered state of the flow.
See also, Mayes ‘763 at 8:64-67 (“Assuming that decision step 206 is answered in the
affirmative (i.e. a translation slot exists for the incoming packet), a decision step 210
determines whether that translation slot references a static translation.”) A person of
ordinary skill in the art would recognize that decision step 210 involves retrieving the
state date stored in the Translation slot data structure described earlier. This retrieval
identifies the last encountered state of the flow.
The processing of packets involves performing state operations specified for the state
of the flow. The ‘763 patent describes numerous possible state operations, depending
on the type of the flow and the current state of the flow. These are described in
Figures 6-12 of the ‘763 patent and the associated written description at Column 5,
Line 35 through Column 15, line 21.
A person of ordinary skill in the art would recognize that the various “decision steps”
described in Figures 6-12 of the ‘763 patent are steps to determine the particular state
of the flow and that the operations described subsequent to those “decision steps” are
state operations specificed for the state of the flow.
For example (as one example of many), decision step 210 and subsequent processing
described at Mayes ‘763 at 9:13-34 starts with the determination of the current state
(i.e. deciding based on the table lookup whether the state information indicates a static
translation) and two different possible sets of state operations based on the state:
 Mayes ‘763 at 9:13-19 (“If decision step 210 is answered in the negative, it can
be assumed the translation slot associated with the inbound packet is a
dynamic translation slot. In that case, a process step 212 will handle the
inbound packet according to a specific algorithm for dynamic translations.”)

Mayes ‘763 at 9:20-23 (“Assuming that decision step 210 is answered in the
affirmative (i.e. the translation slot is a static translation slot), a decision step
214 determines whether the inbound packet is an ICMP frame.”)

Thus, we clearly see in this example that the system described by the ‘763 patent
identifies the state of the flow and performs state operations specified for the state of
the flow. Numerous other examples of identifying the state of the flow and performing
operations specific to that state are decribed in the ‘763 patent. Notably, the patent
repeatedly describes decision steps (based on state information) followed by process
steps specified for the particular state determines by the decision steps. See, for
example, Mayes ‘763 at 9:34-44 (“Assuming that decision step 216 determines… a
process step 220 translates…).

and updating the flow-entry of the existing flow including storing one The flow-entry of the existing flow is updated each time a packet is processed by the
or more statistical measures kept in the flow-entry; and system and whenever the state of the conversational flow changes. For example, the
following state information is updated by the system when the following conditions are
detected:

- Mayes ‘763 at 8:16-17 (“Field 172 must be updated every time a PORT
command is issued”)
- Mayes ‘763 at 7:38-39 (“The connection field 138 is updated each time a
new connection slot is opened or timed out.”)

The updating of the flow-entry of the existing flow includes storing one or more
statistical measures kept in the flow-entry. In particular, the ‘763 patent describes
storing of a “time stamp” (described in the ‘763 patent as simply the “stamp”) for each
translation slot and separately for each connection slot.

Mayes ‘763 at 7:41-45 (“A ‘stamp’ field 142 provides a time stamp indicating
when the translation slot last sent or received a packet. Thus, the stamp field
is updated each time an Internet packet passes from or to the local host.”
[emphasis added]).

Mayes ‘763 at 8:17-19 (“Next, a “stamp” field 174 specifies the time that the
connection was last used. This is used for timing out a connection slot.”)

15
 The system described by the ‘763 patent also tracks and stores the number of bytes
transferred while a particular connection slot is open. Mayes ‘763 at 8:19-23 (“An ‘xfer’
field 176 specifies the total number of bytes transferred while the connection slot is
open. The value in this field will continue to grow as more packets are sent and
received over the connection.”) This represents another example of a statistical
measure that is kept in the flow-entry.

16
d) if the packet is of a new flow, performing any state operations
required for the initial state of the new flow and storing a new flow-
entry for the new flow in the flow-entry database, including storing
one or more statistical measures kept in the flow-entry,
17
The process described in the ‘763 Patent examines each inbound and outbound
packet to determine whether the packet is of an existing flow. Mayes ‘763 at 5:48-51
(“If, on the other hand, such packet was indeed received, a decision step 98
determines whether the host sending the packet is listed in a table of allocated
translation slots.”) See also, Mayes ‘763 at 8:55-58 (“When such a packet is received,
a decision step 206 determines whether a translation slot exists for the global IP
destination address on the packet.”)
When a new connection is detected and the system determines that a free translation
slot is available, process step 108 allocates a translation slot and the NAT system fills
the slot with “various pieces of relevant information”. Mayes ‘763 at 6:16-27
(“Assuming that decision step 100 is answered in the affirmative (i.e. a free translation
slot exists), a process step 108 allocates one such translation slot to the host sending
the packet. The NAT system the[n] fills the newly allocated slot with various pieves of
relevant information (detailed below) inclusing the location hosts’s local IP address and
and a global IP address selected from a pool of available IP addresses… The NAT
system also enters the global and local IP addresses for the new translation slot in the
translation slot table.”)
The “various pieces of relevant information” idenitifed above reflect the initial state of
the connection. The data fields present in the Translation slot database are listed in
Figure 4a of the ‘763 patent. The information in this data structure is described in the
patent at Column 7, lines 18-59. A person of ordinary skill in the art would recognize
this set of information as reflecting the initial state of the connection.
The limitation of “including storing one or more statistical measures kept in the flow-
entry” is met by the fact that the ‘763 patent state tables include a “stamp” field that
stores a time stamp reflecting the time that the translation slot last sent or received a
packet. Mayes ‘763 at 7:41-43 (“A ‘stamp’ field provides a time stamp indicating when
the translation slot last sent or received a packet.”) Since this field is updated every
time a packet is sent or received by a translation slot, it must also be true that this
statistical measure is stored as part of the creation of the new flow-entry for a new flow.
(See also, Claim 20 of the ‘763 patent at 17:20-25 (“The network address system of
claim 16, wherein the translation slot includes a stamp field specifying a time when the
network address translation system created the translation slot…”)
The ‘763 patent also counts the number of bytes transferred by a connection and
stores this statistical information in the flow-entry database. Mayes ‘763 at 8:19-23 (“An
‘xfer’ field 176 specifies the total number of bytes transferred while the connection slot
is open. The value in this field will continue to grow as more packets are sent and
received over the connection.”) This is another example of a statistical measure that is
kept in the flow-entry.
wherein every packet passing though the connection point is received The system described by the ‘763 patent receives both “inbound” and “outbound”
packets coupled to the connection point.
by the packet acquisition device,
For packets inbound from the Internet, the connection point awaits receipt of a packet
and, upon receipt of such a packet, processes that packet. Mayes ‘763 at 8:53-56
(“Process 200 begins at 202 and then a decision step 204 determines whether an
inbound packet has been received. If not, the system simply awaits receipt of such
packet.”)

Packets outbound from the enterprise network are also received at the connection
point. Mayes ‘763 at 5:41-48 (“Fig. 3 details a process that may be employed by
network address translation system 34 upon receipt of a packet from enterprise
network 36. Such outbound packets are received at the inside interface 18a of system
34. The process begins at 94 and in a decision step 96 determines whether an
outbound packet has been received from a host on enterprise network 36. If not, the
system simply awaits receipts of such packet.”)

The fact that every packet passing through the connection point is received by the
packet acquisition device is demonstrated by the fact that various stastical measures
are tracked and stored for every packet sent or received over the connection. Mayes
‘763 at 7:41-43 (“A ‘stamp’ field provides a time stamp indicating when the translation
slot last sent or received a packet.”) See also, Mayes ‘763 at 8:19-23 (“An ‘xfer’ field
176 specifies the total number of bytes transferred while the connection slot is open.
The value in this field will continue to grow as more packets are sent and received over
the connection.”)

18
 The process used in the ‘763 patent for every outbound packet includes identifying the
and wherein at least one step of the set consisting of step (a) and step protocol of the packet. For example, Step 110 of Figure 3 identifies whether the packet
(b) includes identifying the protocol being used in the packet from a is a TCP packet.
plurality of protocols at a plurality of protocol layer levels, such that
the flow-entry database is to store flow entries for a plurality of
conversational flows using a plurality of protocols, at a plurality of
layer levels, including levels above the network layer.

See also the discussion of Step 110 at Mayes ‘763, 6:28-31 (“Now, regardless of how
a translation slot was identified (via step 106 or 108), the next step is a decision step
110 which determines whether the outbound packet is a Transmission Control Protocol
“TCP” packet.”)

A person of ordinary skill in the art would recognize that the TCP protocol operates at
multiple levels, including layers above the network layer.

The ‘763 patent also identifies conversational flows specific to DNS packets. See, for
example, the abstract of the ‘763 patent:

19
 Figure 7 of the patent depicts the process of identifying whether the packet is part of a
conversational flow involving DNS:

The relevant steps of Figure 7 are described at Mayes ‘763 at 11:12-18 (“…a decision
step 268 determines whether the source port value is equal to 53. This implies that the
inbound packet is a DNS packet…”); Mayes ‘763 at 11:24-27 (“…a decision step 270
determines whether the destination port value is equal to 53. If so, the inbound packet
must be a DNS request and should be allowed in.)

A person of ordinary skill in the art would recognize that DNS is a protocol that uses
the application layer (layer 7) of the OSI model.

20
 Furthermore, the ‘763 patent examines packets to determine whether they are part of a
conversational flow associated with the FTP protocol. See, for example, the abstract
of the ‘763 patent discloses that the process specifically identifies FTP data packets
and provides for specific processing steps associated with FTP:

Figure 8 of the ‘763 patent demonstrates that packets are examined to determine
whether they are part of an FTP session (i.e. sport = 20) and provides for further
processing specific to an FTP session if the conversational flow is determined to the an
FTP session.

21
 The specific relevant steps are defined in the ‘763 patent at Mayes ‘763 at 12:44-55 (“If
decision step 286 is answered in the affirmative, a decision step 292 determines
whether the source port value of the inbound packet equals 20. A source port value of
20 indicates that an FTP (file transfer protocol) data connection is being established…
If, however, decision step 292 is answered in the affirmative, a decision step 293
determines whether the inbound packet meets certain FTP security criteria.”)

A person of ordinary skill in the art would recognize that the FTP protocol is an
application layer (layer 7) protocol.

22