throbber
Juniper Networks, Inc. & Palo Alto Networks, Inc.
`v.
`Packet Intelligence LLC
`IPR2020-00336 (U.S. Patent No. Patent 6,665,725)
`IPR2020-00337 (U.S. Patent No. Patent 6,771,646)
`
`Inter Partes Review – Final Hearing
`
`June 9, 2021
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`1
`
`

`

`Instituted Grounds
`
`Patent
`
`Claims
`
`Statutory Basis
`
`Reference
`
`’725 Patent
`
`10, 12, 13, 16, 17
`
`§ 103(a)
`
`Riddle, Baker
`
`’725 Patent
`
`10, 12, 13, 16, 17
`
`§ 103(a)
`
`Riddle, Baker, Yu
`
`’725 Patent
`
`10, 12, 13, 16, 17
`
`§ 103(a)
`
`Riddle, Baker, RFC1945
`
`’646 Patent
`
`1-3, 7, 16, 18
`
`§ 103(a)
`
`Riddle, Ferdinand, Wakeman
`
`’646 Patent
`
`1-3, 7, 16, 18
`
`§ 103(a)
`
`Riddle, Ferdinand, Wakeman, Yu
`
`’646 Patent
`
`1-3, 7, 16, 18
`
`§ 103(a)
`
`Riddle, Ferdinand, Wakeman, RFC1945
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`2
`
`

`

`Burden of Proof for Invalidity
`
`The petitioners bear the burden of
`proving a proposition of unpatentability
`by a preponderance of the evidence.
`
`35 U.S.C. § 316(e)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`3
`
`

`

`Legal Requirements for Obviousness
`
`Petitioners must show that “the differences between the
`subject matter sought to be patented and the prior art are such
`that the subject matter as a whole would have been obvious
`at the time the invention was made to a person having ordinary
`skill in the art to which said subject matter pertains.”
`
`35 U.S.C. § 103
`
`The PTAB must make “a searching comparison of the
`claimed invention—including all its limitations—with the
`teachings of the prior art.’”
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`In re Ochiai, 71 F.3d 1565, 1572 (Fed. Cir. 1995).
`
`4
`
`

`

`’725 Patent Independent Claims
`
`Claim 10
`
`Claim 17
`
`10. A method of performing protocol specific operations
`on a packet passing through a connection point on a
`computer network, the method comprising:
`
`17. A method of performing protocol specific operations
`on a packet passing through a connection point on a
`computer network, the method comprising:
`
`(a) receiving the packet;
`
`(a) receiving the packet;
`
`(b) receiving a set of protocol descriptions…
`
`(b) receiving a set of protocol descriptions…
`
`(c) performing the protocol specific operations on the
`packet…,
`
`(c) performing the protocol specific operations on the
`packet…,
`
`wherein the protocol specific operations include one or
`more parsing and extraction operations on the packet to
`extract selected portions of the packet to form a function
`of the selected portions for identifying the packet as
`belonging to a conversational flow.
`
`wherein the packet belongs to a conversational flow of
`packets having a set of one or more states,
`
`and wherein the protocol specific operations include one
`or more state processing operations that are a function of
`the state of the conversational flow of the packet, the
`state of the conversational flow of the packet being
`indicative of the sequence of any previously encountered
`packets of the same conversational flow as the packet.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`5
`
`

`

`‘725 Patent State-based Claims
`
`Claim 16
`
`Claim 17
`
`16. A method according to claim 10,
`
`wherein the protocol specific operations further include
`one or more state processing operations that are a
`function of the state of the flow of the packet.
`
`17. A method of performing protocol specific operations
`on a packet passing through a connection point on a
`computer network, the method comprising:
`
`(a) receiving the packet;
`
`(b) receiving a set of protocol descriptions…
`
`(c) performing the protocol specific operations on the
`packet…,
`
`wherein the packet belongs to a conversational flow of
`packets having a set of one or more states,
`
`and wherein the protocol specific operations include one
`or more state processing operations that are a function of
`the state of the conversational flow of the packet, the
`state of the conversational flow of the packet being
`indicative of the sequence of any previously encountered
`packets of the same conversational flow as the packet.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`6
`
`

`

`’646 Patent Independent Claims
`
`Claim 1
`
`Claim 7
`
`1. A packet monitor…comprising:
`
`7. A packet monitor…comprising:
`
`(a) a packet acquisition device…;
`
`a packet acquisition device…;
`
`(b) a memory for storing a database comprising flow-entries for
`previously encountered conversational flows to which a received
`packet may belong, a conversational flow being an exchange of
`one or more packets in any direction as a result of an activity
`corresponding to the flow;
`
`(c) a cache subsystem…;
`
`(d) a lookup engine…; and
`
`(e) a state processor…to perform any state operations specified
`for the state of the flow starting from the last encountered state
`of the flow in the case that the packet is from an existing flow, and
`to perform any state operations required for the initial state of
`the new flow in the case that the packet is from an existing flow.
`
`an input buffer memory…;
`
`a parser subsystem…;
`
`a memory to storing a database of one or more flow-entries for
`any previously encountered conversational flows, each flow-
`entry identified by identifying information stored in the flow-
`entry;
`
`a lookup engine…;
`
`a cache subsystem…; and
`
`a flow insertion engine…,
`
`the lookup engine configured such that…,
`
`wherein the operation of the parser subsystem depends on one
`or more of the protocols to which the packet conforms.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`7
`
`

`

`’646 Patent Independent Claims
`
`Claim 16
`
`16. A method of examining packets passing through a connection point on a computer network, each
`packets conforming to one or more protocols, the method comprising:
`
`(a) receiving a packet from a packet acquisition device;
`
`(b) performing one or more parsing/extraction operations on the packet to create a parser record
`comprising a function of selected portions of the packet;
`
`(c) looking up a flow-entry database comprising none or more flow-entries for previously encountered
`conversational flows, the looking up using at least some of the selected packet portions and determining if
`the packet is of an existing flow, the lookup being via a cache;
`
`(d) if the packet is of an existing flow, classifying the packet as belonging to the found existing flow; and
`
`(e) if the packet is of a new flow, storing a new flow-entry for the new flow in the flow-entry database,
`including identifying information for future packets to be identified with the new flow-entry,
`
`wherein the parsing/extraction operations depend on one or more of the protocols to which the packet
`conforms.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`8
`
`

`

`’646 Patent State-based Claims
`
`Claim 1
`
`1. A packet monitor…comprising:
`
`(a) a packet acquisition device…;
`
`(b) a memory for storing a database comprising flow-entries for previously encountered conversational flows
`to which a received packet may belong, a conversational flow being an exchange of one or more packets in
`any direction as a result of an activity corresponding to the flow;
`
`(c) a cache subsystem…;
`
`(d) a lookup engine…; and
`
`(e) a state processor…to perform any state operations specified for the state of the flow starting from the
`last encountered state of the flow in the case that the packet is from an existing flow, and to perform any
`state operations required for the initial state of the new flow in the case that the packet is from an existing
`flow.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`9
`
`

`

`’646 Patent Associative Cache Claim
`
`Claim 3
`3. A packet monitor according to claim 2,
`
`wherein the cache subsystem is an associative cache subsystem including one or more
`content addressable memory cells (CAMs).
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`10
`
`

`

`Level of Ordinary Skill in the Art
`
`The Board adopted the level of ordinary skill in the art found
`in a prior, related proceeding. (Paper 21, 26-27)
`
`[W]e conclude that a person of ordinary skill in the art would have had a
`bachelor’s degree in electrical engineering, computer engineering, computer
`science, or a related field (or its equivalent), and one to two years of experience
`working in networking environments, including at least some experience with
`network traffic monitors and/or analyzers.
`
`IPR2017-00450, Paper 8 at 14.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`IPR2020-00336, Paper 21 at 26-27
`
`11
`
`

`

`Construction of “conversational flow”
`
`Board’s Construction
`
`• “[the] sequence of packets that are exchanged in any direction as a
`result of an activity” (IPR2020-00336, Paper 21 at 31)
`
`• Patent Owner’s Construction
`
`• “the 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—and where some conversational
`flows involved more than one connection, and some even involve
`more than one exchange of packets between a client and server”
`(IPR2020-00336, Paper 7 at 22-23)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`12
`
`

`

`Patent Owner’s Construction Is Proper
`
`The exemplary language that forms part of the specification’s
`explicit definition of conversational flow gives meaning to both
`“conversational flow” and “activity”
`
`“The specification acts as a dictionary when it expressly defines
`terms used in the claims or when it defines terms by
`implication.”
`
`Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996)
`
`The Federal Circuit has previously affirmed constructions based
`on definitional language from the specification that included
`exemplary language. See Realtime Data, LLC v. Stanley, 554 F.
`App’x 923, 932- 33 (Fed. Cir. 2014)
`
`(IPR2020-00336, Paper 26 at 22-24; Paper 32 at 4)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`13
`
`

`

`“activity” implicates a specific client
`
`• “conversational flow” must relate to a conversation, which involves
`an application activity involving the same client.
`
`• A single conversational flow does not relate to every activity of the
`same type.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`(IPR2020-00336, Paper 26 at 25; Paper 32 at 4)
`
`14
`
`

`

`Independent Conversations - Different Activities of Same Type
`
`Different activities of the same application type (e.g., Skype, FTP, etc.) are
`recognized as different conversations
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`(IPR2020-00336, Paper 7 at 40)
`
`15
`
`

`

`Conversational flow ≠ application type
`
`Grouping traffic by application type does not teach recognizing
`conversational flows
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`(IPR2020-00336, Paper 7 at 42)
`
`16
`
`

`

`Activity Instance vs. Activity Type
`
`Conversational flow recognition requires recognizing activity instances on a
`per-client basis
`
`Recognition of Activity Instances
`
`Recognition of Activity Type
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`17
`
`

`

`Flow Overview
`
`’099 Patent at 12:4- 5
`
`’099 Patent at 2:35-37
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`18
`
`

`

`Network activity occurs between specific entities
`
`The specification describes the nature of an activity:
`
`’099 Patent at 2:39-40
`
`’099 Patent at 9:14-19
`
`19
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`

`

`Network activity occurs between specific entities
`
`The specification describes the nature of an activity:
`
`Object and advantage of the invention
`
`’099 Patent at 3:23-25
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`20
`
`’099 Patent at 4:45-47
`
`

`

`flows describe communication between particular devices
`
`’099 Patent at 12:4- 5
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`’099 Patent at 6:35-39
`
`21
`
`

`

`Flow Signatures Include Endpoint Information
`
`’099 Patent at 4:34-36
`
`’099 Patent at 32:43-47
`
`’099 Patent at 13:22-29
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`22
`
`

`

`Claim Interpretation – Specification is an Important Backdrop
`
`Conversational flow must be interpreted in the
`context of the specification.
`
`See Eon Corp. IP Holdings LLC v. Silver Spring Networks, Inc., 815 F.3d 1314,
`1320-23 (Fed. Cir. 2016) (rejecting constructions “untethered to the context of
`the invention” even though they could, “in the abstract, be given such a broad
`meaning”)
`
`Exemplary language in the specification’s definition of
`conversational flow reiterates how a POSITA would
`understand flows.
`
`See Realtime Data, LLC v. Stanley, 554 F. App’x 923, 933 (Fed. Cir. 2014)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`23
`
`

`

`POSITA understands flows similarly
`
`A POSITA would have understood a conversational flow and its
`corresponding activity to relate to a particular client.
`
`See EX2061 ¶¶41, 43-44, 47.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`24
`
`

`

`Specification Embodiments Confirm
`
`Specification embodiments further illustrate that a
`conversational flow relates to specific client activity as
`opposed to an entire class of application activity
`
`• SAP Example
`
`• RPC Example
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`25
`
`

`

`SAP Example – One Conversational Flow
`
`1. Client 1 sends an Initial SAP
`Request (red line) to Server 2
`requesting address information
`about the Print Service.
`
`2. Server 2 sends an SAP Reply (orange
`line) providing the address
`information for its Print Service.
`
`3. Client 1 then sends a Print Request
`(green line) to the Print Service
`available at Server 2.
`
`SAP Reply
`
`SAP
`
`Print
`Service
`
`Print Request
`
`One
`Conversational
`Flow
`
`Initial SAP
`Request
`
`(IPR2020-00336, Paper 26 at 30; Paper 32 at 6-8)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`26
`
`

`

`SAP Example – Two Conversational Flows
`
`1. Client 1 sends an Initial SAP
`Request (red line) to Server 2
`requesting address information
`about the Print Service.
`
`2. Server 2 sends an SAP Reply (orange
`line) providing the address
`information for its Print Service.
`
`3. Subsequently, Client 2 ends a Print
`Request (green line) to the Print
`Service available at Server 2.
`
`SAP Reply
`One
`Conversational
`Flow
`
`SAP
`
`Print
`Service
`
`Print Request
`
`Different
`Conversational
`Flow
`
`Initial SAP
`Request
`
`(IPR2020-00336, Paper 26 at 31; Paper 32 at 6-8)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`27
`
`

`

`RPC Example
`
`RPC Bind
`Lookup Request
`
`1. Client 3 wants to identify the
`connection point for a specific
`application, so it sends an RPC Bind
`Lookup Request to Server 2
`requesting a version of that
`program.
`
`2. Server 2 responds with an RPC Bind
`Lookup Reply “contain[ing] the
`specific Port number…on which
`future transactions will be accepted
`for the specific RPC program.”
`
`RPC
`Bind
`
`RPC Bind
`Lookup Reply
`
`(IPR2020-00336, Paper 32 at 9-11)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`28
`
`

`

`Skype Example – Related but disjointed flows
`
`Skype illustrates how a single network activity can involve related connection flows
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`29
`
`

`

`Skype Example – Related but disjointed flows
`
`Skype illustrates how a single network
`activity (i.e., involving a single client)
`can involve multiple connection flows.
`
`• Video information connection flows
`
`• Audio information connection flows
`
`• Control information connection flows
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`30
`
`

`

`Riddle Does Not Recognize “conversational flows”
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`31
`
`

`

`Riddle Does Not Recognize “conversational flows”
`
`Riddle categorizes traffic into generic “traffic classes” irrespective
`of the clients involved
`
`“Riddle teaches applying ‘policies’ to control traffic classified as to
`type of service required.”
`
`IPR2020-00336, Paper 29 at 8 (internal quotes omitted)
`
`Riddle at 8:48-53
`
`A conversational flow relates to a particular activity, not all
`activities of a generic type.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`32
`
`

`

`Riddle Interpretation of Skype Conversations
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`(IPR2020-00336, Paper 7 at 42)
`
`33
`
`

`

`Riddle Does Not Recognize “conversational flows”
`
`Riddle’s traffic classes are unidirectional
`
`A conversational flow includes traffic flowing in both directions for a particular activity:
`
`Riddle at 8:48-53
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`’099 Patent at 2:38-39
`
`34
`
`

`

`Riddle Does Not Recognize “conversational flows”
`
`• Riddle does not classify traffic per user, but by the
`type of traffic based on properties such as the ports
`being used.
`
`• Petitioners’ allegations that Riddle discloses
`“classifying traffic into client-specific conversational
`flows” is incorrect. IPR2020-00336, Paper 29 at 12 (citing
`Riddle at 8:58-9:11, 10:1-17).
`
`• A traffic class created for a specific IP address would
`not distinguish one client activity from another
`
`• A traffic class created for a specific IP address would
`simply aggregate all traffic for that client IP address
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`35
`
`

`

`Riddle’s Service Aggregates Are Not “conversational flows”
`
`• Traffic classes generically group network
`activity
`
`• Service aggregates simply combine multiple
`traffic classes, providing a larger grouping of
`generic network activity
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`Riddle at 11:21-23
`
`36
`
`

`

`Riddle’s PointCast Traffic Class
`
`• Riddle’s recognition of PointCast traffic is
`based on its traffic classes
`
`• Grouping all PointCast traffic into a single
`class fails to recognize conversational flows
`implicating particular client entities
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`37
`
`

`

`Yu Does Not Recognize “conversational flows”
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`38
`
`

`

`Yu Does Not Recognize “conversational flows”
`
`Yu’s “flows” are simply a different name for traffic matched by
`Riddle’s “traffic classes”
`
`A “flow classification specification” is essentially a “traffic class”
`for capture any traffic matching the specification
`
`Yu at 3:47-49
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`Yu at 3:32-38
`
`39
`
`

`

`Yu Does Not Recognize “conversational flows”
`
`• Yu is not distinguishing activities requested
`by individual clients—it is using simple
`pattern matches defined by a rule in the
`same way conventional monitors matched
`tuples on incoming or outgoing packets.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`IPR2020-00336, Petition at 83
`40
`
`

`

`Yu Does Not Recognize “conversational flows”
`
`• Recognizing traffic for a pre-defined user is
`not the same as recognizing conversational
`flows
`
`• A flow classification specification created for
`a specific IP address would not distinguish
`one client activity from another
`
`• A flow classification specification created for
`a specific IP address would simply aggregate
`all traffic for that client IP address
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`41
`
`

`

`RFC 1945 Does Not Teach “conversational flows”
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`42
`
`

`

`RFC 1945 Does Not Teach “conversational flows”
`
`RFC 1945 defines the Hypertext Transfer Protocol
`(HTTP) version 1.0
`
`• Describing the components of the HTTP protocol
`does not teach using those components to
`identify conversational flows. IPR2020-00336, Paper 26 at
`44-45; EX2061 ¶¶71-72, 86.
`
`• Petitioner’s argument relies on testimony about
`an accused infringing product in a prior
`proceeding
`
`• That testimony has no bearing on what RFC 1945
`teaches a POSITA
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`43
`
`

`

`Petitioners Have Not Shown that Yu Is Prior Art
`
`A reference patent is only entitled to claim the benefit of the filing
`date of its provisional application if the disclosure of the
`provisional application provides support for the claims in the
`reference patent in compliance with § 112.
`
`Dynamic Drinkware, LLC v. Nat’l Graphics, Inc., 800 F.3d 1375, 1380-82 (Fed. Cir. 2015)
`
`Petitioner must demonstrate that the subject matter in Chaffee
`relied upon by Petitioner in its unpatentability contentions is
`sufficiently supported in the Chaffee ’836 provisional, this test
`being in addition to the comparison of claimed subject matter
`required by Dynamic Drinkware.
`
`Intex Recreation Corp. v. Team Worldwide Corp., IPR2018-00859, Paper 128 at 26 (PTAB
`Oct. 21, 2019)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`44
`
`

`

`Yu Claim 1 – Includes MPF Terms
`
`Yu Claim 1
`
`1. A policy engine comprising:
`
`a stream classification module;
`
`a packet input/output module that places received packets in an external packet memory and that notifies
`the stream classification module of the packets in the external packet memory;
`
`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;
`
`a policy enforcement module to enforce policies on the packets, including
`
`a packet scheduler that fragments each packet into cells and schedules enforcement of the policies on each
`cell based on the packet service header;
`
`on-chip packet buffer circuitry to temporarily hold the packets during policy enforcement; and
`
`a plurality of action processors, each action processor performing a particular policy enforcement on a cell
`and routing the cell to a next one of the action processors.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`45
`
`

`

`“module” Is an MPF Term
`
`“‘Module’ is a well-known nonce word that can operate as a substitute for
`‘means’ in the context of § 112, para. 6. As the district court found, ‘‘module’ is
`simply a generic description for software or hardware that performs a specified
`function.’”
`
`Williamson v. Citrix Online, LLC, 792 F.3d 1339, 1350-51 (Fed. Cir. 2015)
`
`Where the claim to be construed contains a means-plus-function or step-plus-
`function limitation as permitted under 35 U.S.C. 112(f), the construction of the
`claim must identify the specific portions of the specification that describe the
`structure, material, or acts corresponding to each claimed function.
`
`37 C.F.R. §42.104(b)(3)
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`46
`
`

`

`Petitioners Have Not Shown that Yu Is Prior Art
`
`• Petitioner has failed to identify the structure
`corresponding to Yu’s “module” terms, which are
`presumptively means-plus-function terms
`
`• Petitioner has not disputed that the ‘725 Patent and
`‘646 Patents are entitled to their provisional filing date
`
`“The ’725 Patent claims priority to Provisional
`Application No. 60/141,903 (“’903 Provisional”), filed on
`June 30, 1999. Petitioners do not accede to this, but for
`IPR assume that the earliest priority date is June 30,
`1999.”
`
`IPR2020-00336, Paper 3 at 9-10
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`47
`
`

`

`No Reason to Combine Riddle and Yu
`
`“[R]ejections on obviousness grounds cannot be sustained by mere conclusory statements;
`instead, there must be some articulated reasoning with some rational underpinning to
`support the legal conclusion of obviousness.”
`
`KSR Int’l Co. v. Teleflex, Inc., 550 U.S. 398, 418 (2007)
`
`[A] statement of similarity, however, does not constitute an articulated reasoning with
`rational underpinning as to why a POSITA would combine elements of one reference with
`another, and why a POSITA would modify the teachings of the references to arrive at the
`claimed invention.
`
`William Wesley Carnes, Sr. Inc. v. Seabaord International Inc., IPR2019-00133, Paper 10 at
`18 (PTAB May 8, 2019)
`
`We have observed that the prejudice of hindsight bias often overlooks that the genius of
`invention is often a combination of known elements which in hindsight seems preordained.
`
`Polaris Indus. v. Arctic Cat, Inc., 882 F.3d 1056, 1068 (Fed. Cir. 2018) (internal quotes
`and citations omitted).
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`48
`
`

`

`No Reason to Combine Riddle and Yu
`
`• Petitioners allege that Riddle and Yu are in the “same field of endeavor” (IPR2020-00336, Paper 3 at
`84)
`
`• Petitioners rely on Yu’s statement that “[f]low classification technique is evolving” (IPR2020-00336
`Paper 3 at 85; Paper 29 at 23)
`
`• Such broad, non-substantive statements cannot meet Petitioner’s burden to prove a motivation to
`combine Riddle and Yu, and confirms that Petitioner’s combination turns on improper hindsight bias.
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`49
`
`

`

`Riddle and Yu Implement Different Design Philosophies
`
`• Riddle teaches a simple, automatic classification solution
`
`• Yu teaches a complex hardware/software combination requiring specialized hardware and regularly
`updated policy databases and software modules
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`50
`
`

`

`Riddle Does Not Teach State-based Limitations
`
`• Riddle never mentions state
`
`• Riddle’s analysis is limited to a single packet – state preservation is not required
`
`[A]lthough Riddle teaches classifying multiple packets in a flow, this classification occurs serially on an
`individual packet by packet basis, rather than relying on state transitions across multiple packets.
`IPR2020-00335, Paper 19 at 19-20
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`51
`
`

`

`Yu Does Not Teach State-based Limitations (‘725)
`
`• Yu summarily mentions state: “stateful packet inspection” (Yu at 4:55-64)
`
`• This passing reference fails to teach the particular requirements of the state-based limitations
`wherein the packet belongs to a conversational flow of packets having a set of one or more states,
`and wherein the protocol specific operations include one or more state processing operations that
`are a function of the state of the conversational flow of the packet, the state of the conversational
`flow of the packet being indicative of the sequence of any previously encountered packets of the
`same conversational flow as the packet.
`
`‘725 Patent at 98:30-37
`
`• To hold otherwise engages in improper hindsight bias
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`52
`
`

`

`Yu Does Not Teach State-based Limitations (‘646)
`
`• Yu summarily mentions state: “stateful packet inspection” (Yu at 4:55-64)
`
`• This passing reference fails to teach the particular requirements of the state-based limitations
`a state processor coupled to the lookup engine and to the flow-entry-database memory, the state
`processor being to perform any state operations specified for the state of the flow starting from the
`last encountered state of the flow in the case that the packet is from an existing flow, and to perform
`any state operations required for the initial state of the new flow in the case that the packet is from
`an existing flow.
`
`‘646 Patent at 36:60-67
`
`• To hold otherwise engages in improper hindsight bias
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`53
`
`

`

`The Prior Art Fails to Teach a “flow-entry database”
`
`Every challenged independent claim of the ‘646 Patent recites a flow-entry database:
`
`• Claim 1: “(b) a memory for storing a database comprising flow-entries for previously encountered
`conversational flows to which a received packet may belong, a conversational flow being an exchange
`of one or more packets in any direction as a result of an activity corresponding to the flow;”
`
`• Claim 7: “a memory to storing a database of one or more flow-entries for any previously encountered
`conversational flows, each flow-entry identified by identifying information stored in the flow-entry;”
`
`• Claim 16: “(c) looking up a flow-entry database comprising none or more flow-entries for previously
`encountered conversational flows, the looking up using at least some of the selected packet portions
`and determining if the packet is of an existing flow, the lookup being via a cache;”
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`54
`
`

`

`The Prior Art Fails to Teach a “flow-entry database”
`
`• Riddle does not mention or suggest a “flow-entry database”; it mentions “database” twice in passing
`See Riddle at 5:65-67 (“However, server 20 may itself act in the capacity of a client when it
`•
`accesses remote databases located at another node acting as a database server.”)
`See Riddle at 12:34-35 (“The knowledge base may be embodied in a file or a relational
`database.”)
`
`•
`
`• Yu only refers to a “policy database”
`See Yu at Fig. 3, 1:26, 2:58, 3:24, 3:53, 4:53
`•
`
`• Ferdinand discloses “data structures” that “store performance statistics relating to the [] data link
`layer.” Ferdinand at 10 (8:3-5).
`
`• Petitioners’ argument that “databases” were known in the art is insufficient to disclose the “flow-entry
`database” limitations, which specifically implicate flow-entries
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`55
`
`

`

`The Prior Art Fails to Teach an “associative cache”
`
`• Riddle never mentions a cache
`
`• Yu refers to a policy cache.
`
`• Regarding flow information, Yu teaches that using a cache for flow information is very difficult.
`See Yu at 1:60-62 (“The distinctions of various implementation makes it difficult to cache a flow
`•
`with its decision in many ways.”)
`
`• Wakeman teaches caches, but Petitioners fail to show why one of skill in the art would have been
`motivated to combine an associative cache with Riddle or Yu
`
`DEMONSTRATIVE EXHIBIT - NOT EVIDENCE
`
`56
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket