`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`As demonstrated in the claim charts below, the Asserted Claims are invalid (a) under one or more sections of 35 U.S.C. § 102 as
`anticipated by Yu and (b) under 35 U.S.C. § 103(a) as obvious over Yu standing alone and as set forth herein, and/or combined with
`the knowledge of a person of ordinary skill in the art, admitted prior art, and/or the additional prior art references discussed in Exhibits
`A1-A16, and B, the contents of which are hereby incorporated by reference into this chart. Although the following charts illustrate
`where Yu discloses the preambles of the Asserted Claims, Palo Alto does not imply by these contentions that the preambles are claim
`limitations.
`
`
`
`
`
`’099
`Claim
`
`[1.pre]
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`A packet monitor for examining
`packets passing through a
`connection point on a computer
`network in real-time, the
`packets provided to the packet
`monitor via a packet acquisition
`device connected to the
`connection point, the packet
`monitor comprising:
`
`Yu discloses a packet monitor for examining packets passing through a connection
`point on a computer network in real-time, the packets provided to the packet
`monitor via a packet acquisition device connected to the connection point.
`
`For example, Yu discloses:
`
`Abstract (“A policy engine for handling incoming data packets. The policy engine
`includes a stream classification module, a data packet input/output module, and a
`policy enforcement module. The policy enforcement module further includes a
`packet scheduler, an on-chip packet buffer circuitry, and a plurality of action
`processors. The stream classification module creates a packet service header for
`each data packet, wherein the packet service header indicates policies to be enforced
`for that data packet. The action processors enforce the policies.”);
`
`2:51-65 (“The architecture 100 includes three major components—a Policy-Based
`Application 102, a Policy engine API 104 (“API” stands for Application Program
`Interface”) and a Policy engine 106. As can be seen from FIGS. 2 and 3, the policy-
`based application 102—such as a firewall, virtual private network (VPN), or traffic
`management—is typically a “legacy” software program residing on a host, equipped
`with its own policy database 202 and flow classifier logic 204.
`
`The policy engine API 104 serves as an interface between the policy application 102
`and the policy engine 106 (via a system bus 105). The policy engine 106 is a
`
`1
`
`Packet Intelligence Ex. 2009 Page 1 of 171
`
`
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`’099
`Claim
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`purpose-built hardware (preferably running at wire speed) that operates on input
`network traffic and network policies and that outputs regulated traffic flows based
`upon the network policies.”); see also Fig. 2, Fig. 3.
`
`
`
`
`
`
`
`
`2
`
`Packet Intelligence Ex. 2009 Page 2 of 171
`
`
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`’099
`Claim
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`
`
`
`
`
`3
`
`Packet Intelligence Ex. 2009 Page 3 of 171
`
`
`
`’099
`Claim
`
`[1.a]
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`
`
`
`(a) a packet-buffer memory
`configured to accept a packet
`from the packet acquisition
`device;
`
`Yu discloses a packet-buffer memory configured to accept a packet from the packet
`acquisition device.
`
`For example, Yu discloses:
`
`Abstract (“A policy engine for handling incoming data packets. The policy engine
`includes a stream classification module, a data packet input/output module, and a
`policy enforcement module. The policy enforcement module further includes a
`packet scheduler, an on-chip packet buffer circuitry, and a plurality of action
`processors. The stream classification module creates a packet service header for
`each data packet, wherein the packet service header indicates policies to be enforced
`for that data packet. The action processors enforce the policies.”);
`
`6:10-15 (“The Packet Input/Output Module 402 receives packets, places the
`received packets in the external packet memory 450 and notifies the Stream
`Classification Module 404 of such packets. Upon completion of all policies
`enforcement, the Packet Input/Output Module 402 transmits the packet from
`external packet memory 450 to the network.”);
`
`6:31-58 (“The Policy Enforcement Module 406 includes a Packet Scheduler 408,
`On Chip packet Buffer(s) 410, and at least one Action Processor 412. The Packet
`Scheduler 408 copies packets from external packet memory 450 to the On Chip
`Packet Buffer 410. After copying the packets to the Packet Buffer 410, packets are
`fragmented into 64 bytes cells. An 8-bit Cell Service Header (FIG. 6) is added to the
`beginning of each 64-byte cell. The Cell Service Header includes a Packet Number
`to uniquely identify a packet in the Policy Enforcement Module pipeline and a Start
`bit and Stop bit to indicate the first and last cell of a packet. A Next AP field,
`together with the AP IDs in the Packet Service Header, indicates to the Policy
`Enforcement Module 406 what is the next destination Action Processor of each cell.
`
`4
`
`Packet Intelligence Ex. 2009 Page 4 of 171
`
`
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`’099
`Claim
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`
`
`
`It is preferable to have the On Chip Packet Buffer 410 because it allows the Action
`Processors 412 very low latency and high bandwidth access to the packets as
`compared with having to access the external Packet Memory 450. In case the next
`Action Processor 412 is busy for a cell, the On Chip Packet Buffer 410 serves as
`temporary storage for that cell. This prevents the blocking of following cells which
`need to go through this same Action Processor 412.
`
`Each Action Processor 412 performs a particular policy enforcement. In addition to
`this, it is capable of reading the required action spec based on the AP pointer on the
`packet Service Header (FIG. 5). Each Action Processor may also have its own input
`and/or output FIFO to buffer the cells.”);
`
`Claim 1 (“wherein the stream classification module creates a packet service header
`for each packet in the external packet memory indicating, based on a policy cache,
`policies to be enforced on that packet;”); see also Fig. 4.
`
`5
`
`Packet Intelligence Ex. 2009 Page 5 of 171
`
`
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`’099
`Claim
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`
`
`
`
`
`6
`
`Packet Intelligence Ex. 2009 Page 6 of 171
`
`
`
`’099
`Claim
`
`[1.b]
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`
`
`
`(b) a parsing/extraction
`operations memory configured
`to store a database of
`parsing/extraction operations
`that includes information
`describing how to determine at
`least one of the protocols used
`in a packet from data in the
`packet;
`
`To the extent Packet Intelligence alleges that Yu does not explicitly disclose this
`claim limitation, this limitation is inherent and/or it would have been obvious in
`view of the knowledge of one of ordinary skill in the art, in view of the references
`identified in Exhibit B, and/or it would have been obvious to one of ordinary skill in
`the art to combine the teaching of Yu with the prior art identified in §C of Palo
`Alto’s Invalidity Contentions.
`
`Yu discloses a parsing/extraction operations memory configured to store a database
`of parsing/extraction operations that includes information describing how to
`determine at least one of the protocols used in a packet from data in the packet.
`
`For example, Yu discloses:
`
`2:66-3:12 (“In a typical embodiment, the policy engine API 104 provides the
`policy-based application 102 access to all the media I/O through a generic operating
`system driver interface. In addition, the API 104 allows the application 104 to
`invoke acceleration functions (shown in FIG. 3 as application processors 206, or
`“AP's”) provided by the policy engine 106. The application processors 206 operate
`based on the stream classifier 207 of the policy engine 106 determining that a packet
`belongs to a particular stream and activating the appropriate action processors 206
`according to action specifications 210 in a policy cache 209. That is, overall system
`performance is enhanced by virtue of the appropriate acceleration functions (action
`processors 206) of the policy engine 106 being activated to regulate the network
`traffic.”);
`
`3:64-67 (“Policy Binding [¶] Policy binding is the process of the flow classifier 204
`binding a stream with its associated action specification and loading the appropriate
`
`7
`
`Packet Intelligence Ex. 2009 Page 7 of 171
`
`
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`’099
`Claim
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`
`
`
`entries (stream specification 208 and action specifications 210) into the policy cache
`209.”)
`
`4:21-28 (“Stream Specification [¶] A stream specification 208, shown in FIG. 3 held
`in policy cache 208 is the criteria used by the stream classifier 207 to uniquely
`identify a stream. In one embodiment, the stream specification 208 is compared to a
`5-tuple in a packet header—source and destination address, source and destination
`port, and protocol type.”);
`
`5:3-17 (“Subsequent packets of the stream are then provided directly to the stream
`classifier 207 of the policy engine 106 via the logical data path 403. Using the
`policy cache 209, the stream classifier 207 determines which action processors 206
`are to be activated for the packets of the stream. Specifically, the stream classifier
`207 matches the packets to a particular stream specification 208 and then, using the
`corresponding action specifications 210, activates the proper action processors 206.
`Significantly, these “subsequent packets” can be acted upon without. any interaction
`to the “host” policy-based application 102. The application need not “see” any
`packets belonging to that stream after the binding (unless the stream is actually
`destined for the host.). The action processors are specialized in executing specific
`action specifications, preferably at the wire speed.”); see also Fig. 3.
`
`8
`
`Packet Intelligence Ex. 2009 Page 8 of 171
`
`
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`’099
`Claim
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`
`
`
`
`
`9
`
`Packet Intelligence Ex. 2009 Page 9 of 171
`
`
`
`’099
`Claim
`
`[1.c]
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`
`
`
`(c) a parser subsystem coupled
`to the packet buffer and to the
`pattern/extraction operations
`memory, the parser subsystem
`configured to examine the
`packet accepted by the buffer,
`extract selected portions of the
`accepted packet, and form a
`function of the selected portions
`sufficient to identify that the
`accepted packet is part of a
`conversational flow-sequence;
`
`Yu discloses a parser subsystem coupled to the packet buffer and to the
`pattern/extraction operations memory, the parser subsystem configured to examine
`the packet accepted by the buffer, extract selected portions of the accepted packet,
`and form a function of the selected portions sufficient to identify that the accepted
`packet is part of a conversational flow-sequence.
`
`For example, Yu discloses:
`
`1:50-62 (“The flow classification is a rule based operation that can be very flexible
`to tune to application needs. For example, it may define a rule to identify packets
`with a pattern of any random byte within a packet, and/or across many packets. The
`flow classifiers may also differ per action processor for performance optimization.
`As a result the matching criteria used by a flow classifier to classify a flow may
`include a specific value, a range, or wildcard on interface port numbers, protocols,
`IP addresses, TCP ports, applications, application data, or any user specifiable
`criteria. The distinctions of various implementation makes it difficult to cache a
`flow with its decision in many ways.”);
`
`2:66-3:12 (“In a typical embodiment, the policy engine API 104 provides the
`policy-based application 102 access to all the media I/O through a generic operating
`system driver interface. In addition, the API 104 allows the application 104 to
`invoke acceleration functions (shown in FIG. 3 as application processors 206, or
`“AP's”) provided by the policy engine 106. The application processors 206 operate
`based on the stream classifier 207 of the policy engine 106 determining that a packet
`belongs to a particular stream and activating the appropriate action processors 206
`according to action specifications 210 in a policy cache 209. That is, overall system
`performance is enhanced by virtue of the appropriate acceleration functions (action
`
`10
`
`Packet Intelligence Ex. 2009 Page 10 of 171
`
`
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`’099
`Claim
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`
`
`
`processors 206) of the policy engine 106 being activated to regulate the network
`traffic.”);
`
`3:22-67 (“Policy [¶] Policies (normally defined by network managers) are
`collectively stored in a policy database 202 accessible to the policy-based
`applications 102 (even conventionally) and describe network traffic behaviors based
`upon business needs. A policy specifies both what traffic is to be subject to control
`and how the traffic is to be controlled. Thus, a policy typically has two
`components—a flow classification specification 203 a and an action specification
`203 b.
`
`Flow Classification Specification 203 a [¶] A flow classification specification 203 a
`provides the screening criteria for the flow classifier logic 204 to sort network
`traffic into flows. A flow classification specification 203 a can be very elaborate, as
`detailed as defining a specific pair of hosts running a specific application.
`Alternately, a flow classification specification 203a can have a simple wildcard
`expression.
`
`Action Specification 203 b [¶] An action specification 203 b describes what to do
`with packets that match an associated flow classification specification 203 a. The
`action specification 203 b can be as simple, for example, as a discard or forward
`decision in the firewall case. It can also be as complicated as IPSec encryption rules
`based on a SA (Security Association) specification.
`
`Flow [¶] All packets that match the same flow classification specification 203 a
`form a flow.
`
`Flow Classifier [¶] Referring again to FIG. 3, a policy decision is at least initially
`derived by a policy-based application from the policy database 202. As discussed
`above, a flow is a stream of correlated packets to which policy decisions apply.
`
`11
`
`Packet Intelligence Ex. 2009 Page 11 of 171
`
`
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`’099
`Claim
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`
`
`
`With the described embodiments in accordance with the invention, referring again
`specifically to FIG. 3, for at least some of the packets, a flow classifier 204
`classifies the packet according to one or more classification specifications 203 a and
`finds one or more corresponding action specifications 203 b. The found action
`specifications 203 b are then provided to the policy cache 209 for later execution by
`the policy engine 106 to enforce the policy.
`
`Policy Binding [¶] Policy binding is the process of the flow classifier 204 binding a
`stream with its associated action specification and loading the appropriate entries
`(stream specification 208 and action specifications 210) into the policy cache
`209.”);
`
`4:46-5:2 (“Referring still to FIG. 3, the population and use of the policy cache 209
`is now discussed in greater detail. As discussed above, the policy-based application
`102 (typically a legacy application) is equipped with its own policy database 202
`and flow classifier logic 204. Some of the packets of a stream are provided (via a
`data path shown logically as 401 in FIG. 3) to the flow classifier 204. The flow
`classifier 204 uses the policy database 202 to determine the action specifications
`203 b that correspond to the policies of the flow to which the stream belongs. The
`action specifications are provided (via the path shown logically as 402 in FIG. 3) to
`the policy cache 209. It should be noted that multiple packets may be required for
`more sophisticated flow classification (stateful packet inspection), since the policy
`decisions (action specifications) may come from different applications which may
`have implemented different flow classifiers. In those cases, the application's flow
`classification logic keeps track of the flow's state until a matching criteria is met.
`Preferably, though, just enough packets of a stream are provided to the flow
`classification logic 204 via theological path 401 to properly determine the action
`specifications 203 b for the stream. At the end of the “learning phase”, the
`
`12
`
`Packet Intelligence Ex. 2009 Page 12 of 171
`
`
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`’099
`Claim
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`
`
`
`application software 102 has uniquely identified a policy for the incoming packet
`stream”);
`
`5:18-34 (“Thus, in summary, upon the completion of the policy binding “learning”
`process, the policy engine 106 may immediately take control of the bound stream
`and execute the appropriate actions in accordance with the action specifications 210
`in the policy cache 209 without any intervention from the “host” (policy-based)
`application. This method also relieves the policy engine 106 hardware from doing
`complicated pattern matching because it can simply compute a hash value (or use
`some other identification function) from the well known fields (which uniquely
`identify a stream) of the packet to find its corresponding policy decisions (action
`specifications 210). The classification need not be done more than once for each
`packet even though there may be multiple applications. As a result, massive
`computing power is not required to do the classification on an ongoing basis. A
`benefit is inexpensive hardware cost for very high performance policy-based
`applications.”); see also Fig 3.
`
`To the extent Packet Intelligence alleges that Yu does not explicitly disclose this
`claim limitation, this limitation is inherent and/or it would have been obvious in
`view of the knowledge of one of ordinary skill in the art, in view of the references
`identified in Exhibit B, and/or it would have been obvious to one of ordinary skill in
`the art to combine the teaching of Yu with the prior art identified in §C of Palo
`Alto’s Invalidity Contentions.
`
`Yu discloses a memory storing a flow-entry database including a plurality of flow-
`entries for conversational flows encountered by the monitor.
`
`For example, Yu discloses:
`
`13
`
`[1.d]
`
`(d) a memory storing a flow-
`entry database including a
`plurality of flow-entries for
`conversational flows
`encountered by the monitor;
`
`Packet Intelligence Ex. 2009 Page 13 of 171
`
`
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`’099
`Claim
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`
`
`
`1:50-62 (“The flow classification is a rule based operation that can be very flexible
`to tune to application needs. For example, it may define a rule to identify packets
`with a pattern of any random byte within a packet, and/or across many packets. The
`flow classifiers may also differ per action processor for performance optimization.
`As a result the matching criteria used by a flow classifier to classify a flow may
`include a specific value, a range, or wildcard on interface port numbers, protocols,
`IP addresses, TCP ports, applications, application data, or any user specifiable
`criteria. The distinctions of various implementation makes it difficult to cache a
`flow with its decision in many ways.”);
`
`3:31-62 (“Flow Classification Specification 203 a [¶] A flow classification
`specification 203 a provides the screening criteria for the flow classifier logic 204 to
`sort network traffic into flows. A flow classification specification 203 a can be very
`elaborate, as detailed as defining a specific pair of hosts running a specific
`application. Alternately, a flow classification specification 203a can have a simple
`wildcard expression.
`
`Action Specification 203 b [¶] An action specification 203 b describes what to do
`with packets that match an associated flow classification specification 203 a. The
`action specification 203 b can be as simple, for example, as a discard or forward
`decision in the firewall case. It can also be as complicated as IPSec encryption rules
`based on a SA (Security Association) specification.
`
`Flow [¶] All packets that match the same flow classification specification 203 a
`form a flow.
`
`Flow Classifier [¶] Referring again to FIG. 3, a policy decision is at least initially
`derived by a policy-based application from the policy database 202. As discussed
`above, a flow is a stream of correlated packets to which policy decisions apply.
`
`14
`
`Packet Intelligence Ex. 2009 Page 14 of 171
`
`
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`’099
`Claim
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`
`
`
`With the described embodiments in accordance with the invention, referring again
`specifically to FIG. 3, for at least some of the packets, a flow classifier 204
`classifies the packet according to one or more classification specifications 203 a and
`finds one or more corresponding action specifications 203 b. The found action
`specifications 203 b are then provided to the policy cache 209 for later execution by
`the policy engine 106 to enforce the policy.”);
`
`4:46-5:34 (“Referring still to FIG. 3, the population and use of the policy cache 209
`is now discussed in greater detail. As discussed above, the policy-based application
`102 (typically a legacy application) is equipped with its own policy database 202
`and flow classifier logic 204. Some of the packets of a stream are provided (via a
`data path shown logically as 401 in FIG. 3) to the flow classifier 204. The flow
`classifier 204 uses the policy database 202 to determine the action specifications
`203 b that correspond to the policies of the flow to which the stream belongs. The
`action specifications are provided (via the path shown logically as 402 in FIG. 3) to
`the policy cache 209. It should be noted that multiple packets may be required for
`more sophisticated flow classification (stateful packet inspection), since the policy
`decisions (action specifications) may come from different applications which may
`have implemented different flow classifiers. In those cases, the application's flow
`classification logic keeps track of the flow's state until a matching criteria is met.
`Preferably, though, just enough packets of a stream are provided to the flow
`classification logic 204 via theological path 401 to properly determine the action
`specifications 203 b for the stream. At the end of the “learning phase”, the
`application software 102 has uniquely identified a policy for the incoming packet
`stream
`
`Subsequent packets of the stream are then provided directly to the stream classifier
`207 of the policy engine 106 via the logical data path 403. Using the policy cache
`209, the stream classifier 207 determines which action processors 206 are to be
`
`15
`
`Packet Intelligence Ex. 2009 Page 15 of 171
`
`
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`’099
`Claim
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`
`
`
`activated for the packets of the stream. Specifically, the stream classifier 207
`matches the packets to a particular stream specification 208 and then, using the
`corresponding action specifications 210, activates the proper action processors 206.
`Significantly, these “subsequent packets” can be acted upon without. any interaction
`to the “host” policy-based application 102. The application need not “see” any
`packets belonging to that stream after the binding (unless the stream is actually
`destined for the host.). The action processors are specialized in executing specific
`action specifications, preferably at the wire speed.
`
`Thus, in summary, upon the completion of the policy binding “learning” process,
`the policy engine 106 may immediately take control of the bound stream and
`execute the appropriate actions in accordance with the action specifications 210 in
`the policy cache 209 without any intervention from the “host” (policy-based)
`application. This method also relieves the policy engine 106 hardware from doing
`complicated pattern matching because it can simply compute a hash value (or use
`some other identification function) from the well known fields (which uniquely
`identify a stream) of the packet to find its corresponding policy decisions (action
`specifications 210). The classification need not be done more than once for each
`packet even though there may be multiple applications. As a result, massive
`computing power is not required to do the classification on an ongoing basis. A
`benefit is inexpensive hardware cost for very high performance policy-based
`applications.”); see also Fig. 3.
`
`To the extent Packet Intelligence alleges that Yu does not explicitly disclose this
`claim limitation, this limitation is inherent and/or it would have been obvious in
`view of the knowledge of one of ordinary skill in the art, in view of the references
`identified in Exhibit B, and/or it would have been obvious to one of ordinary skill in
`
`16
`
`Packet Intelligence Ex. 2009 Page 16 of 171
`
`
`
`’099
`Claim
`
`[1.e]
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`
`
`
`(e) a lookup engine connected
`to the parser subsystem and to
`the flow-entry database, and
`configured to determine using
`at least some of the selected
`portions of the accepted packet
`if there is an entry in the flow-
`entry database for the
`conversational flow sequence of
`the accepted packet;
`
`the art to combine the teaching of Yu with the prior art identified in §C of Palo
`Alto’s Invalidity Contentions.
`
`Yu discloses a lookup engine connected to the parser subsystem and to the flow-
`entry database, and configured to determine using at least some of the selected
`portions of the accepted packet if there is an entry in the flow-entry database for the
`conversational flow sequence of the accepted packet.
`
`For example, Yu discloses:
`
`1:50-62 (“The flow classification is a rule based operation that can be very flexible
`to tune to application needs. For example, it may define a rule to identify packets
`with a pattern of any random byte within a packet, and/or across many packets. The
`flow classifiers may also differ per action processor for performance optimization.
`As a result the matching criteria used by a flow classifier to classify a flow may
`include a specific value, a range, or wildcard on interface port numbers, protocols,
`IP addresses, TCP ports, applications, application data, or any user specifiable
`criteria. The distinctions of various implementation makes it difficult to cache a
`flow with its decision in many ways.”);
`
`2:66-3:12 (“In a typical embodiment, the policy engine API 104 provides the
`policy-based application 102 access to all the media I/O through a generic operating
`system driver interface. In addition, the API 104 allows the application 104 to
`invoke acceleration functions (shown in FIG. 3 as application processors 206, or
`“AP's”) provided by the policy engine 106. The application processors 206 operate
`based on the stream classifier 207 of the policy engine 106 determining that a packet
`belongs to a particular stream and activating the appropriate action processors 206
`according to action specifications 210 in a policy cache 209. That is, overall system
`performance is enhanced by virtue of the appropriate acceleration functions (action
`
`17
`
`Packet Intelligence Ex. 2009 Page 17 of 171
`
`
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`’099
`Claim
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`
`
`
`processors 206) of the policy engine 106 being activated to regulate the network
`traffic.”);
`
`3:31-62 (“Flow Classification Specification 203 a [¶] A flow classification
`specification 203 a provides the screening criteria for the flow classifier logic 204 to
`sort network traffic into flows. A flow classification specification 203 a can be very
`elaborate, as detailed as defining a specific pair of hosts running a specific
`application. Alternately, a flow classification specification 203a can have a simple
`wildcard expression.
`
`Action Specification 203 b [¶] An action specification 203 b describes what to do
`with packets that match an associated flow classification specification 203 a. The
`action specification 203 b can be as simple, for example, as a discard or forward
`decision in the firewall case. It can also be as complicated as IPSec encryption rules
`based on a SA (Security Association) specification.
`
`Flow [¶] All packets that match the same flow classification specification 203 a
`form a flow.
`
`Flow Classifier [¶] Referring again to FIG. 3, a policy decision is at least initially
`derived by a policy-based application from the policy database 202. As discussed
`above, a flow is a stream of correlated packets to which policy decisions apply.
`With the described embodiments in accordance with the invention, referring again
`specifically to FIG. 3, for at least some of the packets, a flow classifier 204
`classifies the packet according to one or more classification specifications 203 a and
`finds one or more corresponding action specifications 203 b. The found action
`specifications 203 b are then provided to the policy cache 209 for later execution by
`the policy engine 106 to enforce the policy.”); see also Fig. 3.
`
`18
`
`Packet Intelligence Ex. 2009 Page 18 of 171
`
`
`
`
`
`
`’099
`Claim
`
`[1.f]
`
`
`PALO ALTO’S INVALIDITY CONTENTIONS
`Exhibit A13: U.S. Patent No. 6,625,150 (“Yu”)
`
`
`Claim Element
`
`U.S. Patent No. 6,625,150 (“Yu”)
`
`(f) a state patterns/operations
`memory configured to store a
`set of predefined state transition
`patterns and state operations
`such that traversing a particular
`transition pattern as a result of a
`particular conversational flow-
`sequence of packets indicates
`that the particular
`conversational flow-sequence is
`associated with the operation of
`a particular application
`program, visiting each state in a
`traversal including carrying out
`none or more predefined state
`operations;
`
`To the extent Packet Intelligence alleges that Yu does not explicitly disclose this
`claim limitation, this limitation is inherent and/or it would have been obvious in
`view of the knowledge of one of ordinary skill in the art, in view of the references
`identified in Exhibit B, and/or it would have been obvious to one of ordinary skill in
`the art to combine the teaching of Yu with the prior art identified in §C of Palo
`Alto’s Invalidity Contentions.
`
`Yu discloses a state patterns/operations memory configured to store a set of
`predefined state transition patterns and state operations such that traversing a
`particular transition pattern as a result of a particular conversational flow-sequence
`of packets indicates that the particular conversational flow-sequence is associated
`with the operation of a particular application program, visiting each state in a
`traversal including carrying out none or more predefined state operations.
`
`For example, Yu discloses:
`
`2:66-3:12 (“In a typical embodiment, the policy engine API 104 provides the
`policy-based application 102 access to all the media I/O through a generic operating
`system driver interface. In addition, the API 104 allows the application 104 to
`invoke acceleration functi